Duplicate geometric object tag

I stumbled onto an object "anatomy" that I can't explain.  As far as I know, it is not causing any problem, but since it seems to me to be an undesirable if not illegal geometry object state, I want to post it looking for any possible explanation.  And, no, sadly, I cannot reproduce it except from itself (see later).

It appears in the leg of the construction of my humanoid "bobbie" which I have placed in a separate model file for observation and analysis:

bobbie_joined_good_undo_leg_only.fea



The issue can be seen in the decomposition of fea.geom (print_geom_objects print_geom_objects.m) or by browsing the fea.geom object in MATLAB workspace.

leg_objects.txt
The complete object listing above contains the subject object, SP19, shown below:

       2:  'SP19', 'brep'
           cutplane pt:   0.410000  0.470000 -0.425000
         cutplane norm:   0.000000  0.000000  1.000000

          --> Gen 3
          1:  'SP19', 'brep'
              cutplane pt:   0.410000  0.470000 -0.150000
            cutplane norm:   0.000000  0.000000  1.000000

             --> Gen 4
             1:  'E6', 'ellipsoid'
               center:  0.410000   0.470000  -0.000000
                radii:  0.055000   0.055000   0.700000
                 axis:  0.000000   0.000000   1.000000

I am concerned that SP19, which is one of the objects that are joined ("+") to create the leg CJ2, has a child with the same tag (SP19).

If you un-join using "undo", the subject object (SP19, above) is there (its lower leg) but it has now been given a different tag, SP21, and it has a child with tag SP21.



SP21 (with SP21 child) shows up in the dissection of the model where SP19 (with SP19 child) was found when it was still joined.

leg_undo_objects.txt
The complete object listing above contains the subject object, SP21, shown below:

 2:  'SP21', 'brep'
     cutplane pt:   0.410000  0.470000 -0.425000
   cutplane norm:   0.000000  0.000000  1.000000

    --> Gen 1
    1:  'SP21', 'brep'
        cutplane pt:   0.410000  0.470000 -0.150000
      cutplane norm:   0.000000  0.000000  1.000000

       --> Gen 2
       1:  'E6', 'ellipsoid'
         center:  0.410000   0.470000  -0.000000
          radii:  0.055000   0.055000   0.700000
           axis:  0.000000   0.000000   1.000000

Is this really a problem or could it cause one?

How could this have happened?

Kind regards,
Randal
 

I didn't completely go through the history to check but I believe it is here due to using the split operation.

The input objects of any geometry operation are stored in the children field, so an operation resulting in two or more objects (such as split or subtract) will have the same children with identical labels. If such an object is reversed, the object will be replaced with the objects in the children field, while the other object(s) still exist with the same children, so to avoid potential conflicts object labels are incremented if the name already exits. If there are any reproducible errors I can check further.

Precise Simulation wrote

I didn't completely go through the history to check but I believe it is here due to using the split operation.

I definitely used (over used probably) the split operation. Ellipses were used to form the upper and lower leg. This was before I understood that joining discards overlapping regions, so I seem to recall explicitly cutting and subtracting parts of the ellipses that I did not want.

I was not very careful to maintain a good pedigree of the various versions as it developed and what I wound up with is two versions of "bobbie" that looked the same, but that behaved differently. Both could be grid generated as individual models, but when placed inside a block, one of them failed grid gen.  So I began looking at the differences using print_geom_objects. That's when I noticed the duplicate name in the same child-parent chain.

Precise Simulation wrote

The input objects of any geometry operation are stored in the children field, so an operation resulting in two or more objects (such as split or subtract) will have the same children with identical labels.

I do think I understand how the split works.

Precise Simulation wrote

If such an object is reversed, the object will be replaced with the objects in the children field, while the other object(s) still exist with the same children, so to avoid potential conflicts object labels are incremented if the name already exits.

However, I don't have a such a good grasp of the undo :-(  IF there really IS a problem, it might be with the undo of some pathological "split on top of split" that I did.  Somehow an incremented tag was used to replaced the tag of the parent and child.

       2:  'SP19', 'brep'
           cutplane pt:   0.410000  0.470000 -0.425000
         cutplane norm:   0.000000  0.000000  1.000000

          --> Gen 3
          1:  'SP19', 'brep'
              cutplane pt:   0.410000  0.470000 -0.150000
            cutplane norm:   0.000000  0.000000  1.000000

             --> Gen 4
             1:  'E6', 'ellipsoid'
               center:  0.410000   0.470000  -0.000000
                radii:  0.055000   0.055000   0.700000
                 axis:  0.000000   0.000000   1.000000

As it turns out, the "bad bobbie" was NOT the one with the "incestuous" 'SP19' but the other one, which, after I made some necessary modifications, did ceased to fail grid generation inside a block... So the issue no longer appears in my work path.  

I think I will just post the failure case in a separate thread so you can see if anything looks amiss.

Precise Simulation wrote

If there are any reproducible errors I can check further.

I certainly will.

Thanks for taking a look and ...
Kind regards,
Randal

randress wrote

Precise Simulation wrote

If there are any reproducible errors I can check further.

I certainly will.

After struggling with the suggestion I was planning to post (which I have since abandoned), I stumbled upon a reproducer.  It is really quite simple and does NOT involve any "undo"s.

1. Create a block: B1.
2. Split the block in half: SP1, SP2
3. Split SP2: SP2, SP3

...and 'SP2' has a child 'SP2':

2:  'SP2', 'brep'
     cutplane pt:   0.500000  0.500000  0.750000
   cutplane norm:   0.000000  0.000000  1.000000

    --> Gen 1
    1:  'SP2', 'brep'
        cutplane pt:   0.500000  0.500000  0.500000
      cutplane norm:   0.000000  0.000000  1.000000

       --> Gen 2
       1:  'B1', 'block'
                 min        max
          x:  0.000000   1.000000
          y:  0.000000   1.000000
          z:  0.000000   1.000000

That's it.  Here is the complete print_geom_objects output:

cube_split_split.txt

 Here are the associated files.

cube_split_split.fea
cube_split_split.fes
cube_split_split.m

So that's what I saw. While it is a bit unsettling to see a parent with the same tag as the child, I cannot say it is a problem.

Kind regards,
Randal

Thank you for the easy steps to reproduce, but yes although maybe intuitive this can happen. When using the undo/revert operation the geometry object names will (or should) be uniqified. As long as you don't see any duplicate object names on the top level geometry operations should work (which are the only ones accessible to the geometry functions).