[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>