# Ellipsoid and intersecting cone fail grid generation

9 messages
Open this post in threaded view
|

## 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.mBoth 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.txtSaved model file: bobbie_head_and_neck.feaBTW, 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
Open this post in threaded view
|

## Re: Ellipsoid and intersecting cone fail grid generation

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

## Re: Ellipsoid and intersecting cone fail grid generation

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

## Re: Ellipsoid and intersecting cone fail grid generation

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

## Re: Ellipsoid and intersecting cone fail grid generation

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

## Re: Ellipsoid and intersecting cone fail grid generation

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

## Re: Ellipsoid and intersecting cone fail grid generation

 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