[cgma-dev] Inconsistency in getEntities for iGeom interface. Causes problems in iRel.

Tue Jul 15 22:16:10 CDT 2014

I think the name gets duplicated at the attribute level; it's only when the
attribute gets interpreted and assigned in CGM that the suffix gets added.
On Jul 15, 2014 8:26 PM, "Rajeev Jain" <jain at mcs.anl.gov> wrote:

> Sorry, I missed this email.
> Yes, you are right. It is for OCC based meshing. The test names
> volumes/surfs etc and then tries to retrieve them.
> You can ignore the test case as we started working on developing other
> missing pieces for OCC geometry based meshing in MeshKit. When entities are
> copied the names can be copied with some an additional letter word under
> some convention.
> Ex. CUBIT uses vol 1 named as mysteel when copied the new vol 2 is called
> mysteel at a etc.
>
> Rajeev
>
>   ------------------------------
>  *From:* shriwise <shriwise at wisc.edu>
> *To:* Paul Wilson <wilsonp at engr.wisc.edu>; "Jain, Rajeev" <
> jain at mcs.anl.gov>; CGMA Development <cgma-dev at mcs.anl.gov>
> *Sent:* Tuesday, July 15, 2014 10:29 AM
> *Subject:* Re: [cgma-dev] Inconsistency in getEntities for iGeom
> interface. Causes problems in iRel.
>
>  Bump.
>
> On 07/11/2014 08:15 PM, Paul Wilson wrote:
>
> Rajeev,
>
> You are mentioned in the git logs as the inspiration for the copy_attrib
> test that Patrick mentioned.  (a few years ago)
>
> I wonder if you have any thoughts on what the purpose and/or requirements
> are for this capability?  You probably needed it for RGG based on OCC?
>
> Paul
>
> On 07/11/2014 07:21 PM, Patrick Shriwise wrote:
>
> Hi all,
>
> I'm currently working on the changes to iGeom that Paul previously
> proposed. I've hit one test when built with OCC (copy_attrib) that suggests
> that tags are expected to be copied along with an entity when using iGeom
> functions like copyEnt or subtractEnt. Is this the case? Are these specifc
> tags that are supposed to be copied if they exist on the original entity?
>
> Also to be clear this has become an issue because for volume entities we
> now use the RefVolume to get the volume Body and make a copy of that body
> using the GeometryModifyTool. The Body we make a copy of does not have the
> tags associated with the RefVolume. As a result the new Body and the
> corresponding RefVolumethat we return from the function does not have the
> original tags.
>
> These tags can be transferred to the new entity before leaving the
> function of course, but we're looking for the proper way to handle this
> situation. Mainly it would be good to know if there is a particular tag or
> tags that should be copied over to new entity upon it's creation.
>
> Cheers,
>
> Patrick
>
>
> On 06/23/2014 03:06 PM, Paul Wilson wrote:
>
> Hi everyone,
>
> Patrick and I have discussed this and have come up with the following
> proposal for a revision of how iGeom_CGMA handles RefVolumes and Body's.
>
>    1. All references to iBase_REGION will refer only to entities of type
>    RefVolume in CGM.
>    2. All entities that are returned by iGeom will be RefEntities and not
>    CubitEntities
>    3. At the time of loading file, based on an option based to
>    iGeom_load(), all entities of type Body in CGM that contain more than a
>    single volume, will be converted to RefGroup's and tagged to distinguish
>    them from the original RefGroup's
>
> The last of these may be subject to the most conversation, but it seemed
> like a useful approach to use because it:
>
>    - had little to no effect on the API of iGeom
>    - preserves access to CGM/ACIS bodies
>    - is the least intrusive in the implementation of iGeom_CGMA
>
> 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
>
> On 06/17/2014 09:00 AM, Jane Hu wrote:
>
> 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 at gmail.com> wrote:
>
> See comments below...
>
>
>  On Mon, Jun 16, 2014 at 10:22 AM, Paul Wilson <wilsonp at 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 at 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 at wisc.edu>
> wrote:
>
>  Hi Jane,
>
>  Will the ref_volumes() method return RefEntities?
>
>  Patrick
>
> On Jun 15, 2014, at 3:56 PM, Jane Hu <janejhu at gmail.com> wrote:
>
>   Look 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 at 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
>
>
> --
> Patrick C. Shriwise
> Research Assistant
> University of Wisconsin - Madison
> Engineering Research Building - Rm. 428
> 1500 Engineering Drive
> Madison, WI 53706(608) 446-8173
>
>
> --
> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
> 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
>
>
> --
> Patrick C. Shriwise
> Research Assistant
> University of Wisconsin - Madison
> Engineering Research Building - Rm. 428
> 1500 Engineering Drive
> Madison, WI 53706(608) 446-8173
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20140715/a77a6463/attachment-0001.html>