[cgma-dev] copying iGeom entities in occ...
Paul Wilson
wilsonp at engr.wisc.edu
Wed Aug 6 02:17:37 CDT 2014
Hi all,
So....
It seems that finish_copy() is called from 3 places.
* make_RefEdge() - effectively a copy operation of a refEdge
* make_RefFace() - effectively a copy operation of a RefFace
* copy_body() - effectively a copy operation for a Body
The first 2 of these already have Boolean arguments with default values
that determine whether or not finish_copy() is called.
The last of these does not have such a Boolean argument and always calls
finish_copy().
I'll note that there is also a method called prepare_for_copy() that is
always called under the same conditions as, but before finish_copy().
I'm a little stumped about what exactly finish_copy() does since it
_/appears to/_ delete all the attributes, but it is called when the
"copy_attribs" flag is true for make_RefEdge().
I hesitated from digging deeper into the prepare_for_copy() and
finish_copy() methods but I wonder if there is something happening that
we don't see in their calls to:
* GeometryQueryTool::instance()->ige_export_geom() [from
prepare_for_copy], and
* GeometryQueryTool::instance()->ige_import_geom() [from finish_copy]
Some of the concepts get pretty involved at this point...
Paul
On 08/05/2014 04:57 PM, Timothy Tautges wrote:
>
> Remember, changing the interface will break compatibility with cubit.
> Also, this approach looks like flailing without understanding why the
> behavior is coded the way it is. Finally, iGeom should provide an
> interface to exactly the same code behavior as CGM functions do, and
> modifications meant only to change behavior between cgm vs iGeom
> interfaces should not be done.
>
> On Aug 5, 2014 10:13 PM, "Rajeev Jain" <jain at mcs.anl.gov
> <mailto:jain at mcs.anl.gov>> wrote:
>
> Hi Patrick,
>
> Good work.
> How about we make another argument to the copy function?
> With this argument the blue code will be controlled. The
> argument's default will be true -> so nothing changes.
> For your application the argument will be false (don't clear the
> attributes of the copied entities).
>
> Rajeev
>
> ------------------------------------------------------------------------
> *From:* shriwise <shriwise at wisc.edu <mailto:shriwise at wisc.edu>>
> *To:* "cgma-dev at mcs.anl.gov <mailto:cgma-dev at mcs.anl.gov>"
> <cgma-dev at mcs.anl.gov <mailto:cgma-dev at mcs.anl.gov>>
> *Sent:* Tuesday, August 5, 2014 3:49 PM
> *Subject:* Re: [cgma-dev] copying iGeom entities in occ...
>
> A little more info. Looks like this problem comes from the
> finish_copy call in GMT. If I comment the lines in blue, my new
> functions for copying tag data from one entity to another work as
> expected.
>
> My thought is to add a flags for these functions with regards to
> copying entity tag data/ attribute info. In the GMT functions the
> default will maintain the status quo (do not copy the attribute
> data) whereas in the iGeom interface the default will be to copy
> the tag/attribute data. Does this sound acceptable for now? As of
> yet this is the only change I will need to make outside of the
> itaps dir in CGM.
>
> Cheers,
>
> Patrick
>
> CubitStatus GeometryModifyTool::finish_copy( TopologyBridge
> *&new_bridge,
> TopologyBridge *old_bridge )
> {
> //Remove attributes on underlying entities of virtual geometry
> //entities which do not have corresponding RefEntities.
> DLIList<TopologyBridge*> bridge_list;
> bridge_list.append( old_bridge );
> GeometryQueryTool::instance()->ige_remove_attributes( bridge_list );
>
> //Remove attributes on original entity and children
> DLIList<RefEntity*> child_list;
> RefEntity *ref_ent = CAST_TO( old_bridge->topology_entity(),
> RefEntity );
> ref_ent->get_all_child_ref_entities( child_list );
> //child_list.append( ref_ent );
> CubitAttribUser::clear_all_simple_attrib( child_list );
> child_list.clean_out();
> child_list.append( ref_ent );
> CubitAttribUser::clear_all_simple_attrib( child_list );
>
>
> //Restore virtual
> //Could create virtual geometry here so the Topology Bridge can
> change
> bridge_list.clean_out();
> bridge_list.append( new_bridge );
> TopologyBridge *tmp_bridge_before = new_bridge;
> GeometryQueryTool::instance()->ige_import_geom( bridge_list );
> assert( bridge_list.size() == 1 );
> if( tmp_bridge_before != bridge_list.get() )
> new_bridge = bridge_list.get();
>
> //make the RefEntities
> Curve *curve = NULL;
> Surface *surface = NULL;
> Lump *lump = NULL;
> BodySM *body = NULL;
>
> RefEntity *new_ref_ent = NULL;
> if( (curve = CAST_TO( new_bridge, Curve ) ) != NULL )
> new_ref_ent = GeometryQueryTool::instance()->make_RefEdge(
> curve );
> else if( (surface = CAST_TO( new_bridge, Surface) ) != NULL )
> new_ref_ent = GeometryQueryTool::instance()->make_RefFace(
> surface );
> else if( (lump = CAST_TO( new_bridge, Lump) ) != NULL )
> new_ref_ent = GeometryQueryTool::instance()->make_Body(
> lump->bodysm() );
> else if( (body = CAST_TO( new_bridge, BodySM) ) != NULL )
> new_ref_ent = GeometryQueryTool::instance()->make_Body( body );
>
> //actuate the attributes on everything
> child_list.clean_out();
> new_ref_ent->get_all_child_ref_entities( child_list );
> child_list.append( new_ref_ent );
> GeometryQueryTool::import_actuate( child_list );
>
> //Remove attributes on new entity and children
> child_list.clean_out();
> new_ref_ent->get_all_child_ref_entities( child_list );
> CubitAttribUser::clear_all_simple_attrib( child_list );
> child_list.clean_out();
> child_list.append( new_ref_ent );
> CubitAttribUser::clear_all_simple_attrib( child_list );
>
> CGMApp::instance()->restore_previous_attribute_states();
> return CUBIT_SUCCESS;
> }
>
> On 08/05/2014 03:18 PM, shriwise wrote:
>> Just checked and this fails when built w/ CUBIT as well.
>>
>> Patrick
>> On 08/05/2014 03:13 PM, shriwise wrote:
>>>
>>> Hi all,
>>>
>>> I just ran into an interesting problem in CGM built with OCC.
>>> When an entity is copied, the original loses all user-applied
>>> tag information (or so it seems). I understand why a copy might
>>> not keep data from the original, but for the data to disappear
>>> from the original altogether seems like incorrect behaviour to me.
>>>
>>>
>>> I wrote a test as an example of this below. The test fails on
>>> the red line. Any ideas as to why? I've tracked the number of
>>> tags on the entity and they seem to disappear in line 5804 of
>>> iGeom_CGMA.cc.
>>>
>>> Any help or insight for this would be very appreciated! I'm
>>> close to finishing my updates to the iGeom interface and this
>>> seems to be the last piece of the puzzle.
>>>
>>>
>>> bool tag_copied_ent_test(iGeom_Instance geom)
>>> {
>>>
>>> int err;
>>>
>>> //create a tag
>>> iBase_TagHandle test_tag;
>>> std::string name("test_tag");
>>> iGeom_createTag(geom, &name[0], 1, iBase_INTEGER, &test_tag,
>>> &err, name.length());
>>> CHECK( "ERROR: could not create tag" );
>>>
>>> //create a test entity
>>> iBase_EntityHandle cyl;
>>> iGeom_createCylinder(geom, 5.0, 5.0, 0.0, &cyl, &err);
>>> CHECK( "ERROR: could not create the cylinder" );
>>>
>>> //set a value for this tag on the original
>>> int value = 6;
>>> iGeom_setIntData(geom, cyl, test_tag, value, &err);
>>> CHECK( "ERROR: could not set the tag data" );
>>>
>>> //create a copy
>>> iBase_EntityHandle copy;
>>> iGeom_copyEnt(geom, cyl, ©, &err);
>>> CHECK( "ERROR: could not copy the entity" );
>>>
>>> //check to see if the tag is accessible
>>> int bytes;
>>> iGeom_getTagSizeBytes(geom, test_tag, &bytes, &err);
>>> CHECK( "ERROR: could not get the tag size" );
>>>
>>> if (bytes != sizeof(int)) return false;
>>>
>>> iGeom_getIntData(geom, cyl, test_tag, &check_value, &err);
>>> CHECK( "ERROR: could not get the tag data" );
>>>
>>> if (check_value != value) return false;
>>>
>>> //cleanup
>>> iGeom_destroyTag(geom, test_tag, 1, &err);
>>> CHECK( "ERROR: could not destroy tag" );
>>>
>>> iGeom_deleteEnt(geom, cyl, &err);
>>> CHECK( "ERROR: could not delete entity" );
>>>
>>> iGeom_deleteEnt(geom, copy, &err);
>>> CHECK( "ERROR: could not delete entity" );
>>>
>>> return true;
>>> }
>>>
>>> --
>>> Patrick C. Shriwise
>>> Research Assistant
>>> University of Wisconsin - Madison
>>> Engineering Research Building - Rm. 428
>>> 1500 Engineering Drive
>>> Madison, WI 53706
>>> (608) 446-8173
>>
>> --
>> Patrick C. Shriwise
>> Research Assistant
>> University of Wisconsin - Madison
>> Engineering Research Building - Rm. 428
>> 1500 Engineering Drive
>> Madison, WI 53706
>> (608) 446-8173
>
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20140806/e14bb256/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6244 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20140806/e14bb256/attachment-0001.bin>
More information about the cgma-dev
mailing list