[Gmsh] Multilevel mesh partition element interface quality

Andre Nicolle andre at cfdandip.co.uk
Tue Feb 5 06:30:47 CET 2013


Hi Christophe

Thank you for revisiting this issue. It is helpful to know that it is 
possibly not just an implementation problem. I have retried the mesh of 
the human STL. Summarising, the problem does not seem to have gone away 
with the latest version of gmsh. I tried both the self built svn version 
and the nightly build from the website (64bit) on the 2/2/2013 and found 
no difference between them. As a way of determining if there was any 
particular problem I also did a quick parameter study using different 
meshing algorithms "Mesh.Algorithm" and partitioning methods 
"Mesh.RemeshParametrization". in all cases the resolution was set to 
"Mesh.CharacteristicLengthFactor=0.05" which produces a 2d surface mesh 
of around 80,000 triangles.

As before the partitioning is around the waist line of the human as 
shown in the file attached error_partition.jpg. The meshing algorithm we 
had the most success with was the "Frontal" where the elements were 
evenly spread as can be seen in the attached files face_q.jpg and 
face_mesh.jpg.

I have found that Delaunay or MeshAdapt options have difficulty meshing 
around the human limb extremities such as the feet. The example file 
attached frontal_foot.jpg shows a good quality mesh which can be 
produced at any resolution. When using Delaunay or MeshAdapt I found 
that the elements get substantially coarser around relatively sharp 
edges as can be seen in file meshadapt_foot.jpg. This problem gets worse 
as the resolution is increased.

I have also tried each of the seven RemeshParametrization as I was 
interested to see the effect of this parameter.  It seems that options 
7,1 both do not have bad elements around the partition regardless of the 
mesh resolution. However the problem with these options the arms and 
feet get cut off as can be seen in file mis_feet.jpg. This occurs 
regardless of the meshing algorithm.

The only RemeshParametrization option where this does not happen is 4,5 
however both algorithms suffer from poor elements on the partition region.

I hope this information helps in some degree in solving the problem we 
are encountering. If I can help any further please let me know.

Thanks

Andre

On 01/02/2013 01:14, Christophe Geuzaine wrote:
> Hi Andre - Could you try again with a recent build and tell us if things improved?
>
> Thanks,
>
> Christophe
>
> On 31 Oct 2012, at 06:18, Andre Nicolle <andre at cfdandip.co.uk> wrote:
>
>> Dear gmsh user group
>>
>> I have been struggling with meshing a stl file of a human mesh. The stl surface is in good shape with a closed surface which when loaded into gmsh and meshed using the procedure outlined in https://geuz.org/trac/gmsh/wiki/STLRemeshing forms a three-dimensional mesh. Unfortunately the tetrahedron element quality is very poor. On further investigation we found that this was caused by poor quality elements on the 2D surface after the surface was remeshed. We tried using  Mesh.Algorithm: 1 = MeshAdapt, 2=Automatic, 5=Delaunay, 6=Frontal and found that in general Frontal gave us the best elements which were all very good quality except on the interface between the multilevel mesh partitions.  Information on the partition stage of 2-D meshing is given below.
>>
>> Attached is a picture showing the line-up of poor quality elements around the waist of the human. Nearly all the other 2-D triangular elements have a mesh quality indicator gamma > 0.5, however elements on theinterface have gamma approximately 0.03 which we believe is where the 3-D mesh problem is starting from.
>>
>> Could somebody give us some advice on how best to solve this problem as I imagine it is a mistake on our implementation. If further information is required please let me know what would be helpful to diagnose the problem.
>>
>> Any help would be gratefully received
>>
>> Andre
>>
>> gmsh version 2.6.1
>>
>> Info    : Meshing surface 200 (Compound surface, MeshAdapt)
>> Warning : Wrong topology: Genus=0, Nb boundaries=0, AR=1
>> Info    : -----------------------------------------------------------
>> Info    : --- Split surface 200 in 2 parts with Multilevel Mesh partitioner
>> Info    : Building graph...
>> Info    : Partitioning graph...
>> Info    : Launching Chaco graph partitioner
>> Info    : Done partitioning graph
>> Info    : *** Mesh partition: level (1-0) is ZERO-GENUS (AR=5, NB=1)
>> Info    : *** Mesh partition: level (1-1) is ZERO-GENUS (AR=4, NB=1)
>> Info    : Multiscale Partition SUCCESSFULLY PERFORMED : 2 parts (3.26 s)
>> Info    : *** Starting parametrize compounds:
>> Info    : Parametrize Compound Line (2) = 1 discrete edge
>> Info    : Parametrize Compound Surface (203) = 201 discrete face
>> Info    : Parametrizing surface 203 with 'convex map'
>>
>>
>> Warning : Mesh generation error summary
>> Warning :     1 warning
>> Warning :     0 errors
>> Warning : Check the full log for details
>>
>>
>> <test.jpg>_______________________________________________
>> gmsh mailing list
>> gmsh at geuz.org
>> http://www.geuz.org/mailman/listinfo/gmsh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: error_element.jpg
Type: image/jpeg
Size: 33363 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20130205/37d0bdc4/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: error_partition.jpg
Type: image/jpeg
Size: 95408 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20130205/37d0bdc4/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: face_mesh.jpg
Type: image/jpeg
Size: 94656 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20130205/37d0bdc4/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: face_q.jpg
Type: image/jpeg
Size: 16083 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20130205/37d0bdc4/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: frontal_foot.jpg
Type: image/jpeg
Size: 41145 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20130205/37d0bdc4/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meshadapt_foot.jpg
Type: image/jpeg
Size: 31077 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20130205/37d0bdc4/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mis_feet.jpg
Type: image/jpeg
Size: 58080 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20130205/37d0bdc4/attachment-0006.jpg>