Hi Christophe, thanks for getting back to me.
That makes sense for Frontal-Delaunay for quads. Since it seemed to be working very well on certain surfaces, I wasn't sure if the observed phenomena was a bug or just an algorithmic limitation.
Here are two screenshots of a mesh generated with HXT to describe what I meant by a bit coarse. The surface mesh is very nice and regular, but the first row of tetrahedra appear to be rather stretched away from the surface elements, even though the size field grading is not that large. I suppose a simple solution here is to, in my size callback, just multiply the size by some constant factor like 0.9 for 3D generation the tetrahedra generated by HXT will be closer to regular.
lochfunc
variable and GetH
, SetH
methods), but I agree that perhaps there is no actual nice external interface for a callback function. Maybe this is just not a viable option and HXT is just the way to go.On a related note, it seems like for 3D mesh generation the resulting mesh from the Delaunay or HXT generation also is a bit coarse relative to the size field. I may be using thing incorrectly (I am just specifying "Algorithm3D" = 10
), or is this just the nature of the Delaunay algorithm? How much work would it take to hook up the Frontal 3D (Netgen) to allow for a user specified size callback? It seems like Netgen may already have support for something like this.
I have had success meshing in 2D with a size callback (set from the C++ API with gmsh::model::mesh::setSizeCallback
) + the Frontal-Delaunay algorithm, but when I try to use the Frontal-Delaunay for quads some of the surfaces in my model will not be meshed according to the size field. It appears to use the size field for most of the surfaces, and it's just a few, often exactly rectangular, which are "missed" and have no new nodes inserted. See below for an example, the curves are meshed according to the size field but the mesh size is not correct in the middle surface:
For comparison, this is what it looks like with the standard Frontal-Delaunay algorithm and same size field:
I'm wondering if this is a known restriction or bug, or if I need to specify something else before generating the mesh? Reading the paper it seems like this shouldn't be an issue, and many models are meshed just fine.
Thanks so much!
Hello, I have an interesting usage question that I was hoping to get some help with.
I want to generate a 2D mesh for a surface but instead of specifying an element size function, I'd love to be able to just keep refining the mesh until all triangles are within an acceptable quality factor. In general I'm interested in planar surfaces which have some narrow and some large open regions, so it seems like it might be possible to just keep inserting points given the initially generated poor quality triangulation until the triangles meet some sort of constraint.
As a bonus, being able to control the element growth rate would be awesome too, but this might be a bigger ask for the mesh generator. This is different than what I think is the more standard usage where we want to refine within certain regions to a desired element size. Thanks for any suggestions or help you might be able to provide!
Awesome, thanks so much for the very speedy response @arthurbawin! That sounds great and for now I'll keep using the octreeSizeField
branch as is.
Hi @arthurbawin, I have been playing around with your AutomaticMeshSizeField
option and it seems to work well for what I am looking for. I had a few questions poking around the code though that I wonder if you could help me with.
I noticed that there has been some more recent development on both the octreeSizeField
and sizeFieldIso_fix
branches since the latest merge to master
back in January. I'm wondering, if I only need 3D and isotropic (no 2D, no anisotropic), is there a suggested branch I should use for the most up to date/refined versions of the feature? There seems to be a lot of new code in the octreeSizeField
branch (just doing a git diff
) but perhaps none of it would even affect the cases I'm looking at and sticking with the master
branch is best?
Thanks so much for your help! Any tips or suggestions you have for testing things out are very much appreciated.
Hello, I have an interesting usage question that I was hoping to get some help with.
I want to generate a 2D mesh for a surface but instead of specifying an element size function, I'd love to be able to just keep refining the mesh until all triangles are within an acceptable quality factor. In general I'm interested in planar surfaces which have some narrow and some large open regions, so it seems like it might be possible to just keep inserting points given the initially generated poor quality triangulation until the triangles meet some sort of constraint.
As a bonus, being able to control the element growth rate would be awesome too, but this might be a bigger ask for the mesh generator. This is different than what I think is the more standard usage where we want to refine within certain regions to a desired element size. Thanks for any suggestions or help you might be able to provide!