Ellipsoid and intersecting cone fail grid generation

[1.13 Build 20.10.299]
After our brief discussion of unnecessary complexity, I decided I had better try to grid my humanoid. I had done so when it was just a torso but not since.  It failed.  I began amputation (arm, leg, ...) until I found that the problem lies with the ellipsoid head atop a conic neck.

I used the print_geom_objects() script to "dissect" the model into:

>> print_geom_objects(headAndNeck)
 --> Gen 0 (Active Objects)
 1:  'E9', 'ellipsoid'
   center:  0.500000   0.470000   1.050000
    radii:  0.085000   0.090000   0.120000
     axis:  0.000000   0.400000   1.000000

 2:  'C1', 'cone'
   center:  0.500000   0.500000   0.820000
    rad_1:  0.060000
    rad_2:  0.050000
   length:  0.150000
     axis:  0.000000  -0.200000   1.000000

MATLAB commands:
bobbie_head_and_neck.m

Both gmsh and builtin mesh tools failed to generate a mesh. gmsh generated a 2D result:



Error details:
bobbie_head_and_neck_gmsh.txt

... and the builtin seemed to have a problem with 'brep' object type which does not seem to be present (ellipsoid and cone):



Error details:
bobbie_head_and_neck_builtin.txt

Saved model file:
bobbie_head_and_neck.fea

BTW, in this exercise I gained greater appreciation for 1) print_geom_objects - its output was cut/paste to recreate the test case using the GUI and 2) the "undo" of a deleted object as I deleted part (neck) and tried grid generation on the head (it did not fail). Then "undo" the deleted neck and delete the head and tried the grid generation with it (it also did not fail)... Turns out it took both head and neck to reproduce the problem...

Kind regards,
Randal

Firstly, unfortunately if Gmsh fails the built-in mesh generator most likely won't work either.

So I think the main issue is that you have overlapping bodies leading to quite thin regions (although not as extreme as the propeller blade). The mesh generator has to respect all boundaries and when encountered with a really thin or small boundary with respect to the rest of the geometry it either has to mesh really small cells almost everywhere (leading to a very dense mesh), or sliver elements leading to poor quality cells, neither of this is good. More expensive sofwtare actually implemenet defeaturing algorithms to remove details from CAD drawings to enable meshing.

In this case you can avoid the edges by simply joining the head with neck, or optionally create an extra neck and subtracting it from the head. You can also export the geometry and try to mesh it in Gmsh manually.

Precise Simulation wrote

So I think the main issue is that you have overlapping bodies leading to quite thin regions (although not as extreme as the propeller blade). ...

With the blade I can easily see the thin/sharp region, however it concerns me that I cannot visualize just where such a region would be for the head and neck....I need to be able to recognize this myself.

Precise Simulation wrote

In this case you can avoid the edges by simply joining the head with neck, or optionally create an extra neck and subtracting it from the head. You can also export the geometry and try to mesh it in Gmsh manually.

Now I am really confused :-(... while I can see that joining the two relieves what sharpness there is (I can see this somewhat, but as I said it just doesn't look that sharp), I do NOT see how the subtraction trick solves a thing (although it clearly does - I tried it)

Does this mean that in general where you have overlapping objects (which I am doing like crazy in other parts of the humanoid model) joining them is always best?  It seems to work for the incomplete humanoid:



Sorry I am being so "dense" on this one.  I just want to understand how I can avoid this in future.

Kind regards,
Randal

Before meshing all overlapping objects are decomposed into minimal regions, in this case this results in a very thin region which is hard to mesh





I have unfortunately not been able to fix the geometry engine to automatically fix/merge this. To avoid/minimize this issue you can try to merge geometry objects so that the number of overlapping regions is reduced or eliminated before meshing.

Precise Simulation wrote

Before meshing all overlapping objects are decomposed into minimal regions, in this case this results in a very thin region which is hard to mesh

Thanks for taking the time to help me "see" this. I do understand - I can see that the overlapped volume is small, but it just does not seem to be that thin relative to the other volumes.

Precise Simulation wrote

I have unfortunately not been able to fix the geometry engine to automatically fix/merge this.

This I also understand. I am not hoping (or even asking for a fix/enhancement) I just want to be able to do the best with current capabilities.

Precise Simulation wrote

To avoid/minimize this issue you can try to merge geometry objects so that the number of overlapping regions is reduced or eliminated before meshing.

It sounds as if merging (joining, "+") geometry objects before meshing is a good general rule. For my use-case, since you have provided a convenient means for inserting slices/cut-planes to be used for integration, I do not see any downside to merging all components of the geometry for a "subject" model which is being suspended in water and through which current flow is to be analyzed. (I can always "undo" the merge if I want to make changes and then re-merge.)  Does this sound like a good general rule?

I remain intrigued by the fact that the "head and neck" issue was also solved by creating a "plug and socket" version (which seems to me to have the same sharpness in the geometry, although no small regions - they all become part of the neck) by duplicating the neck and subtracting it from the head.  (As I write this, I sense that I may be beginning to get a feel for the problem :-)

This brings me to what could be a great help in my use-case.  When I mesh my overall problem in preparation for running the solver, whatever subject model(s) I have are all enclosed by a "body" of water.  I have found that I do not have to "subtract" the subject model from the water to get a result.  However, there are, of course, times when the meshing fails.   I cannot merge the subject model(s) and the water because they all may have separate conductivity.  BUT would I get better (or more likely to succeed) mesh results if I made it a practice to modify the "water" component to contain "cut outs" of all the subject models by subtracting them from it?

Thanks for the discussion and
Kind regards,
Randal

randress wrote

I can see that the overlapped volume is small, but it just does not seem to be that thin relative to the other volumes.

Maybe I should have pointed it out more clearly but this very thin extra boundary sliver (look at the zoomed in picture) is maybe 1/100th or less of the overall size of the other boundaries. I think this is caused by the cylinder cutting just exactly above one of the boundaries of the ellipsoid creating this effect.



If you don't actually need multiple subdomains (to define different material coefficients or equations etc) it is always better to merge the geometry objects, as otherwise the mesh generator has to mesh each subdomain individually and match them up, which can lead to a wore off mesh.

However, if you enclose the whole object in a block it shouldn't matter too much as no extra boundaries will be created (no boundaries are actually intersecting).

I know we need to wind this up. But this is being very helpful....just a couple more comments.

Precise Simulation wrote

Maybe I should have pointed it out more clearly but this very thin extra boundary sliver (look at the zoomed in picture) is maybe 1/100th or less of the overall size of the other boundaries. I think this is caused by the cylinder cutting just exactly above one of the boundaries of the ellipsoid creating this effect.

Thanks! Yes, that is what I could not actually see - perhaps if I were able to rotate the view you have there it would pop out at me.   I think I may be getting it now.   When I look at it with FEATool, I look at the volumes which overlap with what seems like enough room to prevent small slivers of volume intersection:



But now I am wondering if what you are telling me (though I cannot see it with FEATool) is that the surfaces of the meshing polyhedrons for the head and for the neck are intersecting and it is THESE boundary/surface intersections that generate the tiny slivers.... is that correct??

Precise Simulation wrote

If you don't actually need multiple subdomains (to define different material coefficients or equations etc) it is always better to merge the geometry objects, as otherwise the mesh generator has to mesh each subdomain individually and match them up, which can lead to a wore off mesh.

However, if you enclose the whole object in a block it shouldn't matter too much as no extra boundaries will be created (no boundaries are actually intersecting).

That is a great help!

Hopeful that with your affirming response, we are done here for a while...Kind regards,
Randal

The issue is that the vertical boundary edge of the ellipse (black lines), are extremely close (but does not exactly match up with) the conic intersecting boundary face.

I think that if you actually compute the intersection [&], zoom in, and possibly enable transparency (in the Options > Axis/Grid Settings... menu) it will be evident where and what the issue is.

Note that, although the "Join" [+] operation eliminates the sliver/issue in this case (and is recommended in general to reduce unnecessary subdomains), it is not a "magic" fix since if you just offset the intersection a little bit it might end up on the "outside" of the intersecting shapes and thus not be removed with the operation (the "join" operation simply discards all inner boundaries and surfaces of the intersecting shapes).

Precise Simulation wrote

I think that if you actually compute the intersection [&], zoom in, and possibly enable transparency (in the Options > Axis/Grid Settings... menu) it will be evident where and what the issue is.

Well, just as you say... here it is!



Thanks for your patience!!

Kind regards,
Randal