geom_add_gobj and unique object{}.tag

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

geom_add_gobj and unique object{}.tag

randress
This post was updated on .
In an earlier post (Basic Use: "Functions: geom_get_tags, geom_uniqify_tag, geom_update_tags obsolete?",  a code snip was given to determine if a tag is unique before adding an object with that tag using geom_add_gobj.

Precise Simulation wrote
Something like this should be sufficient:
  all_tags = cellfun( @(o)o.tag, mygeo.objects, 'UniformOutput', false );
  is_tag_unique = ismember( tag, all_tags );
If I recall the geom.tags field is generally not used for command line/script usage. But you should ensure you don't have geometry objects with duplicate tags (you can manually set the tags when you create/define an object).
First, (and I never even noticed it until I began this post), it looks like the sense of the is_tag_unique is reversed and so it should be:
 is_tag_unique = ~ismember( tag, all_tags );  % not (~) inserted
or
tag_is_not_unique = ismember( tag, all_tags ); 

And it does seem to accurately determine whether or not 'tag' is in the tag of any mygeo.objects{}.tag entry.

However, I was surprised when I called "geom_add_gobj" with a newly created object whose tag checked as unique using the above test.... I was surprised to find that when the object that was added, its tag was changed from the "unique" one that I had assigned to another one.

In the following example script: Objects B1 and B2 are created and added to an empty geometric object, geo. They are then subtracted (B1-B2) leaving only one object, CS1.  A third block is created and given the tag B1 which checks (using above code snip) as not being contained in the geometry, geo.  But when this third object is added, its tag is changed to B3. And the resulting model geometry contains CS1 and B3, not CS1 and B1.

reuseStaleTag.m

I am not saying that this is a bug, I am just trying to understand whether or not this or any other uniqueness test can be used to determine before hand, how to be certain that the tag of an object being added using geom_add_gobj will not be modified.  I would have thought that 'uniqueness' would enough.  But it seems that there is persistent memory of which tags have been used in the past and, even though the objects with those tags are no longer present in the geometry, their tags are not available for use with newly added objects.

If there is not a good way, then can I simply read the tag from geo.objects{ length( geo.objects) }.tag ) after the geom_add_gobj? ... but I had rather know before hand.

Any help would be greatly appreciated...

Kind regards,
-Randal
Reply | Threaded
Open this post in threaded view
|

Re: geom_add_gobj and unique object{}.tag

Precise Simulation
Administrator
The join, subtract, intersect, and transform operations store the original input objects in the "children" field of the resulting geometry object, and the complete tag checking recursively checks every object and its children. This is to ensure that the "undo" GUI operation will not introduce geometry objects with the same tag.

randress wrote
If there is not a good way, then can I simply read the tag from geo.objects{ length( geo.objects) }.tag ) after the geom_add_gobj? ... but I had rather know before hand.
As I wrote in my last reply "geom_add_gobj" appends new objects last so you can get it with:

  geom = geom_add_gobj( geom, new_gobj );
  new_gobj = geom.objects{end};
  new_tag = new_gobj.tag;
Reply | Threaded
Open this post in threaded view
|

Re: geom_add_gobj and unique object{}.tag

randress
Precise Simulation wrote
The join, subtract, intersect, and transform operations store the original input objects in the "children" field of the resulting geometry object, and the complete tag checking recursively checks every object and its children. This is to ensure that the "undo" GUI operation will not introduce geometry objects with the same tag.
I see... I also notice that recursively checking all the children, while I am curious, seems to be beyond what I would want to do, especially if I can make the alternative post-add peek work for me.

Precise Simulation wrote
As I wrote in my last reply "geom_add_gobj" appends new objects last so you can get it with:

  geom = geom_add_gobj( geom, new_gobj );
  new_gobj = geom.objects{end};
  new_tag = new_gobj.tag;
I did remember :-), but I wanted to be sure I understood before I went ahead with it.  What I did NOT know was the usefulness, perhaps necessity, of using the 'end' index/method.  I would have simply used
geom.objects{length(geom.objects)};
...which I can now see could possibly get me in trouble.  Thanks for your kind patience.  Soon I will knuckle down doing actual FEA and leave off tool making :-)

Kind regards,
Randal