The last of these may be subject to the most conversation, but it
seemed like a useful approach to use because it:
If a user does NOT pass in the option (e.g.
"CONVERT_BODY_TO_GROUP"), then no bodies will be accessible
through iGeom. If a user does pass in this option, any call to
iGeom_getEntSets will return both the original RefGroups and the
additional RefGroups that were generated automatically from
Bodies. It will be up to the user to filter between them using
the available tag.
Finally, since every RefVolume in ACIS always has a Body in which
it is a member, it seems best to only convert Bodies that contain
>1 RefVolume to avoid creating far more RefGroups than
necessary.
We'd like to embark on these changes soon, but welcome any
comments or feedback. I'm sure we've missed something!
Paul
So, I will add RefVolume to the return list of iGeom_get_adjacent_entities() as the result of the discussion.
CubitEntity only has derived classes of RefEntity and CubitCoordinateSystem, iGeom_CGMA.cc only uses RefEntity as instance of the object.
Jane
On Mon, Jun 16, 2014 at 11:35 AM, Jane Hu <janejhu@gmail.com> wrote:
See comments below...
On Mon, Jun 16, 2014 at 10:22 AM, Paul Wilson <wilsonp@engr.wisc.edu> wrote:
Hi Jane,
I think this needs a thorough review! Patrick and I hunted through iGeom_CGMA and found some inconsistencies in a few places.
First, there is an inconsistency between returning pointers to RefEntity and pointers to CubitEntity. This is probably less important, but should probably be resolved in any change.
I see RefEntity is inherited from CubitEntity, and CubitEntity is a pure virtual class. So even you got pointers to CubitEntity, you have to instantiate it to RefEntity objects.
Second, there are places where the geometry is queried for entities of dimension=3 (returning RefVolumes) and places where the geometry is queried for entities of type=iGeom_REGION (== Body).
In this case, I can return both bodies and refvolumes, so after user gets the refentity list back, he can cast to see if they are bodies or refvolumes, and choose to keep what ever he needs.
This means that 2 calls into the interface that should resolve to the same entity may not do so for both reasons.
All of this is related to the fundamental difference between the iGeom types (equivalent to vertex, edge, face, volume) and the CGM/ACIS types (equiavlent to vertex, edge, face, volume, body). I think Tim's suggestion is the best, but will require some substantial effort.
Paul
On 06/16/2014 10:14 AM, Jane Hu wrote:
I see in iGeom_CGMA.cc file, function iGeom_get_adjacent_entities, if asks for 3-D refentities, it returns body list. In CGM, bodies are not necessary to be 3-D entities, it may contain single surface or shell. Should we change the return to be only refvolumes which are 3-D entities (I prefer this, makes more sense)? Or I can return both bodies and refvolumes in the returned refentity list. Depending on your user case, I can return one of the two choices.
Jane
On Mon, Jun 16, 2014 at 9:32 AM, Jane Hu <janejhu@gmail.com> wrote:
Yes, it returns a list of refVolume's which are RefEntities.
Jane
On Sun, Jun 15, 2014 at 11:55 PM, Patrick Shriwise <shriwise@wisc.edu> wrote:
Hi Jane,
Will the ref_volumes() method return RefEntities?
PatrickLook at line 6454, if you have body's pointer, directly call ref_volumes() will work. It's not an iGeom interface function, but you can access it in iGeom.
Good luck!
Jane
On Sat, Jun 14, 2014 at 8:55 AM, Patrick Shriwise <shriwise@wisc.edu> wrote:
Hi Jane,
I looked around for this but didn't see it, is there a specific line/function you were thinking of? Good to know the ref_volume information is so easy to get to, but it doesn't seem that its part of the iGeom interface. The issue being that there's no way to access a body's volumes via iGeom.
Cheers,
Patrick
On 06/13/2014 11:26 PM, Jane Hu wrote:
Is there a way to get volumes within bodies via iGeom?
See example in iGeom_CGMA.cc, body->ref_volumes(volumes).
Jane
-- Patrick C. Shriwise Research Assistant University of Wisconsin - Madison Engineering Research Building - Rm. 428 1500 Engineering Drive Madison, WI 53706 (608) 446-8173
--
Jane Hu
Asst. Researcher
Dept. of Engineering Physics
UW @ Madison
"And we know that for those who love God, that is, for those who are called according to his purpose, all things are working together for good." (Romans 8:28)
--
Jane Hu
Asst. Researcher
Dept. of Engineering Physics
UW @ Madison
"And we know that for those who love God, that is, for those who are called according to his purpose, all things are working together for good." (Romans 8:28)
--
Jane Hu
Asst. Researcher
Dept. of Engineering Physics
UW @ Madison
"And we know that for those who love God, that is, for those who are called according to his purpose, all things are working together for good." (Romans 8:28)
--
Jane Hu
Asst. Researcher
Dept. of Engineering Physics
UW @ Madison
"And we know that for those who love God, that is, for those who are called according to his purpose, all things are working together for good." (Romans 8:28)
-- -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://bit.ly/pphw-cal Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu Faculty Director, Advanced Computing Infrastructure
--
Jane Hu
Asst. Researcher
Dept. of Engineering Physics
UW @ Madison
"And we know that for those who love God, that is, for those who are called according to his purpose, all things are working together for good." (Romans 8:28)
--
Jane Hu
Asst. Researcher
Dept. of Engineering Physics
UW @ Madison
"And we know that for those who love God, that is, for those who are called according to his purpose, all things are working together for good." (Romans 8:28)
-- -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://bit.ly/pphw-cal Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu Faculty Director, Advanced Computing Infrastructure