Dear Geordie, Thank you very much for your reply.
You are right, GMSH does not generate zero volume tetrahedra. I think the issues with the finite element simulations are due to a combination of my Matlab script and GMSH's volume meshing routine. When loading the volume mesh into COMSOL a minimum quality factor of 6E-10 (average quality 0.66) is obtained, which is rather poor. I think this is primarily due to stretched tetrahedra, which due to rounding errors may have lead to the interpretation of 'zero volume' elements. I also noticed that more recent versions of GMSH have the tendency to fill a volume with 'super nodes' that connect to many surface nodes. After optimisation with COMSOL the minimum quality factor could be improved to 3E-2 (average quality 0.69) . Aside: The mesh statistics use a quality metric that is worked out for each tetrahedra in the mesh and is proportional to d_i/d_o, where d_i would be the diameter of the largest sphere entirely enclosed in the tetrahedra, and d_o is the diameter of the smallest sphere that can entirely enclose a tetrahedra. This is normalised so that quality=1 for a equilateral shape. For my simulations an ideal mesh has tetrahedrons with approximately the same volumes, where each node is part of 4-10 tetrahedrons and where tetrahedrons are not distorted. Do you know of any ways in GMSH to prevent 'super nodes' and encourage more consistent volumes when generating a volume mesh? Thank you again for your help. Kind regards, David On Tue, May 26, 2015 at 1:47 AM, Geordie McBain <[email protected]> wrote: > 2015-05-26 2:06 GMT+10:00 David Love <[email protected]>: > > Dear Sir/Madam, > > > > I have been experiencing difficulties generating a volume mesh (.geo and > > .msh) from a surface mesh (.stl) generated in matlab. The main issue is > that > > I end up with zero volume tetrahedra (elements with four collinear > points) > > which causes difficulties in subsequent finite element simulations. > > > > I have attached an example of a surface mesh (.stl) that I start off > with. I > > then use the procedure outlined in the following link to create the > volume > > mesh (.geo and .msh): > > > http://fengl.org/2012/05/21/converting-stl-surface-mesh-to-volume-mesh-using-gmsh/ > > > > My questions are: > > - Is there a way to avoid zero volume tetrahedra or does the issue > originate > > from the matlab generated stl file? Do you have a suggestion to avoid > this > > issue? > > Hello. I had a go at your STL surface and it seemed to work here. > > I meshed it with the attached, no frills, .geo file. > > To check that the mesh was O. K., I solved a Poisson problem on the > volume with uniform forcing and zero Dirichlet conditions using P1 > elements in FreeFem++, using the attached .edp script. > > It computes the volume as 0.54956, the area as 15.7748, and the > integral of the solution as 0.000286442. > I don't think that this would work if there were degenerate > elements. Is it possible that the error is in the solver rather than > the mesh? > > > > - Is there a possibility of generating a volume mesh in GMSH by defining > the > > surface boundary in an equation? For instance if I describe my shape in > form > > of a triple sinusoidal (as done in the matlab code) and then tell GMSH to > > mesh the inner volume. If so could you point me towards some examples? > > I don't think that this can be done in a .geo file, but your first > approach of generating the STL externally and merging it into Gmsh > should work as you expected. > > I'm using gmsh 2.9.4 (compiled under 64-bit Debian from SVN sources), > in case that matters. > -- David Love PhD Candidate in Physics Cavendish Laboratory University of Cambridge Office: +44 (0)1223 764169 Email: [email protected]
_______________________________________________ gmsh mailing list [email protected] http://www.geuz.org/mailman/listinfo/gmsh
