geom_add_gobj and unique object{}.tag

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

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;

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