[cgma-dev] copying iGeom entities in occ...
Patrick Shriwise
shriwise at wisc.edu
Wed Aug 6 09:08:21 CDT 2014
That is very interesting...
It seems to me to indicate that either the attributes are being copied
in a way that is unseen in GMT and that they are not accessible by CATag
in itaps or that there is an error handling this flag.
At any rate, expected behavior in CGM and iGeom are not aligning right
now it seems. I'm going to hold off on transferring tag data in
functions such as copyEnt for now. I will however, include the functions
for copying tag data and creating iGeom entsets for any Body containing
more than one RefEntity upon loading a file.
As we continue this discussion, I will add or omit the tag data copying
in as is appropriate based on our decisions.
As for the topic at hand, my naive opinion is that attributes on the
original should never be removed and transferring these attributes
should be optional in both cases. I can't think of a scenario in which
you would expect data do be deleted from the original upon copying it.
It sounds like this may be the case, but its buried pretty deep? Is that
right, Paul?
Patrick
On 08/06/2014 02:17 AM, Paul Wilson wrote:
> 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
--
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/20140806/fc9c2892/attachment.html>
More information about the cgma-dev
mailing list