# Duplicate geometric object tag

5 messages
Open this post in threaded view
|

## 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.feaThe 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.txtThe 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.txtThe 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
Open this post in threaded view
|

## Re: Duplicate geometric object tag

 Administrator 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.
Open this post in threaded view
|

## Re: Duplicate geometric object tag

 This post was updated on . 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.feacube_split_split.fescube_split_split.mSo 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