Unexpected duplication of objects

After creating and combining 3 objects (B1, S1, S2 --> CJ1, CJ2) the undo operation produces 6 objects - B1, S1, S2, B1, S1, S2.  

Here is the scripted object creation: B1 containing S1, B1-S1, then S2 (smaller than S1) but concentric with it.
create_geometry.m

After generating a grid using the default grid size, note the presence of S2 at the center.



But when a slice is plotted (x<.5),  note that S2 in the center does NOT appear.



This is the first sign that something is wrong.

And when CJ1 and CJ2 are decomposed by geom_split_object, duplicate objects with duplicate tags result:

Running:
split_geometry.m

... produces this:

>> split_geometry
Begin with objects:
Objects (by tag):
1:  CJ1
2:  CJ2
Results in objects:
Objects (by tag):
1:  B1
2:  S1
3:  S2
4:  B1
5:  S1
6:  S2
see FEATool gui window for grid slice...

The only thing that I can think of that may have caused this is that S2 does not actually overlap (does not contain common points <x,y,z> with) the subdomain formed by B1-S1, but rather S2 is wholly contained within the spherical void (I wondered if this is a proper subdomain) formed by the shell.  Even so, I would expect you would wish to prevent this type of construction (or deconstruction).

Kind regards,
Randal

Thank you for the report, a couple of issues here.

Mesh visualization with grid cell selection is "dumb" in that it only plots cells for which all vertices fulfill the selection expression. In this case plotting x<0.6 should probably show you the inner sphere. Moreover, you can also use "plotbdr(fea)" and "plotsubd(fea); alpha(0.5)" to see the resulting boundaries and subdomains.

On the other hand combining CS1+S2 should technically not work as CSG operations (join, subtract, intersect) with non-touching objects should fail (there should be no need to merge them to mesh them), I have to look in to what is going on here.

Lastly, yes the splitting is "unintelligent" and a remnant of the old geometry engine that could not separate objects from operations that resulted in multiple objects. For example, subtracting a box from another that cuts it in to two, now generates two distinct objects with the same children. It is not quite clear to me how best to address this issue when performing undos, as the simple storing and restoring "children" approach does not quite work anymore.

Precise Simulation wrote

Mesh visualization with grid cell selection is "dumb" in that it only plots cells for which all vertices fulfill the selection expression. In this case plotting x<0.6 should probably show you the inner sphere.

So it does! Even x<.51 works.   Viewing the grid is important to me in order to see where it needs to be refined and where not, thus maximizing grid cell economy.  Thanks for this tweak!

Precise Simulation wrote

Moreover, you can also use "plotbdr(fea)" and "plotsubd(fea); alpha(0.5)" to see the resulting boundaries and subdomains.

Looking forward to trying these.

Precise Simulation wrote

On the other hand combining CS1+S2 should technically not work as CSG operations (join, subtract, intersect) with non-touching objects should fail (there should be no need to merge them to mesh them), I have to look in to what is going on here.

Ah..."non-touching". I figured I had violated the rules.  The reason I was doing this was in an effort to place multiple boundaries around a current source (the inner sphere) so as to better control the mesh size in the block subdomain.  So I was adding an intervening surface/boundary on which to specify a grid size between that for the inner sphere surface and for the block walls.... The subtraction that created the void was probably not necessary. So I should be able to avoid this.
 

Precise Simulation wrote

Lastly, yes the splitting is "unintelligent" and a remnant of the old geometry engine that could not separate objects from operations that resulted in multiple objects.

I assume that I am using the upgraded geometry engine, correct? I am doing nothing to specify it...I figured that this undo problem was because I was allowed to violate the Combine Objects non-touching rule.

Question: So long as an undo is not attempted in these cases, does the model geometry act (grid, subdomains and boundaries, etc.) just as if there were uniquely named children?

Precise Simulation wrote

For example, subtracting a box from another that cuts it in to two, now generates two distinct objects with the same children. It is not quite clear to me how best to address this issue when performing undos, as the simple storing and restoring "children" approach does not quite work anymore.

Hmmm... I see what you mean.... Perhaps if a combination results in multple objects, then any "undo" must be done on all of them... what you "do" is to undo the combination... all results of a combine operation would have to be linked...Ok I'm getting in way over my head .... I'll stop :-)

As always, I very much appreciate your taking the time to discuss these issues... and

Kind regards,
-Randal

I have updated the geometry engine to detect csg operations that doesn't result in anything to address this issue (all forms of non intersecting geometry objects). I've also added new fillet, chamfer and split by cutplane/cutline options in the "menu" of Geometry mode that might be useful.

Precise Simulation wrote

I have updated the geometry engine to detect csg operations that doesn't result in anything to address this issue (all forms of non intersecting geometry objects).

Thanks for the fix...I'll expect to get my "hand slapped" if I ever try to do that again :-)

Precise Simulation wrote

I've also added new fillet, chamfer and split by cutplane/cutline options in the "menu" of Geometry mode that might be useful.

Hmmm that DOES sound interesting...

Again, thanks for the fix and the enhancements. I really appreciate the time and effort.

Kind regards,
Randal

Precise Simulation wrote

I've also added new fillet, chamfer and split by cutplane/cutline options in the "menu" of Geometry mode that might be useful.

Oh, this is NICE!  Very happy to retire my lame orthogonal-model splitter scripts :-)

Being able to split only the objects of interest and only at the planes of interest and only once is VERY useful.  And the splits can be done while constructing the objects of interest.  For example, a model of a person can have splits in a leg and an arm and the torso and can be used and re-use in any number scenarios/locations without having to split the whole model again and again for EACH integration... AND all the anticipated integration planes can be integrated from the same post-processing integration form for all objects!

Not to diminish the benefit of the chamfer and fillet - features that I just realized while writing this post. FEA novice that I am, I just now realize that much of the distortion of results that occurs at edges and corners of objects due unrealistic sharp edges can be eliminated.  The visual realism added by smoothing and tapering contributes to a more realistic simulation result and relaxes the need to hyper-grid the model at these surface intersections.

In addition, together, these mods (split, fillet/chamfer) mean that more complex models can be more easily built within FEATool.  This reduces the need to get models elsewhere, which if imported could mean that some FEATool capability is lost.

Very happy regards,
Randal

randress wrote

Very happy to retire my lame orthogonal-model splitter scripts :-)

You scripts were certainly not lame, and very impressive for someone who just picked up Matlab a few months ago. I really do appreciate all the time and effort you are putting in.

randress wrote

For example, a model of a person ... This reduces the need to get models elsewhere, which if imported could mean that some FEATool capability is lost.

If your end goal is to model a "somewhat realistic" person I'm sure it will be much easier and quicker to download a premade cad model and go from there. There are some repositories here and there for free cad models such as for example https://grabcad.com The STEP and IGES CAD formats should at least technically be lossless with respect to the internal BREP format used by the geometry engine (except for maybe modeling history). Triangulated and faceted formats such as STL and OBJ on the other hand can not resolve non-planar surfaces as accurately (kind of like SVG compared to JPEG image formats).

Precise Simulation wrote

I really do appreciate all the time and effort you are putting in.

Well, I am quite rewarded when your add enhancements in with bug-fix builds :-)   The truth is that when I can build something that helps me (especially to avoid tedious or repetitive tasks), I enjoy it. And as I have stated previously, your explanations and examples have GREATLY accelerated the learning curve for me. Most of what I have done is orchestrating calls and functions that you have shown me... I like examples!

Precise Simulation wrote

If your end goal is to model a "somewhat realistic" person I'm sure it will be much easier and quicker to download a premade cad model and go from there. There are some repositories here and there for free cad models such as for example https://grabcad.com The STEP and IGES CAD formats should at least technically be lossless with respect to the internal BREP format used by the geometry engine (except for maybe modeling history). Triangulated and faceted formats such as STL and OBJ on the other hand can not resolve non-planar surfaces as accurately (kind of like SVG compared to JPEG image formats).

Thanks for pointing me to grabcad.  I did know about it and have found it very helpful. E.g., I have selected propellers to be used as electrodes. The suggestion to use STEP and IGES for FEATool imports is VERY helpful.  

As far as the human model is concerned, for the moment a "stick" figure human body will suffice.  But eventually I would like to be able to use an accurate model like "James".
http://grabcad.com/library/james-human-body-for-scale-1

Something like that adds a sort of informal "visual validation" to the work.  I had used "him" in some other FEA S/W trial with some success, however when I tried to import "his" STEP model into FEATool some months ago, I had some difficulty - don't recall just what.  But FEATool has improved since then (and so have I :-), so that may be a "doable do" now. I need to give it another try.

Thank you for your thoughtful attention, time and effort,
Randal