[Gmsh] Thank you & possible Gmsh have memory leak issues?
cgeuzaine at ulg.ac.be
Tue Apr 1 14:56:23 CEST 2008
CEM ALBUKREK wrote:
> Dear Prof. Christophe Geuzaine:
> First I would like to express my great appreciation of the work you have
> done with Gmsh, which I have been experimenting with as a CFD
> consultant. The package is very capable, concise and user friendly - I
> think it has non-academic use potential and I would recommend it to my
> colleagues. Now coming to the "headache" portion of my message, I would
> like to get some feedback from you on the below questions, which were
> triggered by seemingly excessive memory usage in volume meshing.
> I have a test case consists of ~200,000 facets of STL closed-solid
> surface enclosed in a slightly offset rectangular box, built
> parametrically using GMSH geo language. So I am trying to mesh the
> volume between the STL surface and the rectangular box. The 1D and 2D
> meshing works fine on the outer surface. Finally in the 3D step, for
> tetgen meshing, RAM usage grows monotonously past 3gigs and finally the
> process exits with a memory allocation error.
> To see if the problem was with the STL mesh quality or simply the size,
> I setup a similar problem with a sub-section of the STL geometry, such
> that I have 130,000 facets. Again the memory usage grew significantly,
> past 2gigs, but I was able to obtain a volume mesh before the memory
> limit was reached.
> So, 132,000 STL surface facets results in 15.8million tetrahedra and
> consumes about 2.3 gig RAM.
> 1) Are the above memory requirements expected or are they indicative of
> a memory leak?
Hi Cem - that sounds about right: Gmsh currently generates about 7
million tetrahedra per GB of RAM (it can load/display about 12 million
tets per GB).
> 2) What's your recommended upper limit for STL facet count to obtain a
> volume mesh with ~4gig ram? (In here I am not so concerned about
> performance, but rather the ability to obtain a volume mesh)
The problem is that by default Gmsh adapts the sizes of the tets in the
volume to match the sizes of the triangles on the surface (unless you
explicitly specify a background mesh). Maybe you don't really need the
interior mesh to be that refined?
We've just added an option to control this (it should be available in
tomorrow's nightly snapshot): if you set
Mesh.CharacteristicLengthExtendFromBoundary = 0;
Mesh.CharacteristicLengthMax = 0.05; // <-- change this!
then the volume mesh will simply use the max size specified.
> 3) If the memory requirements make sense to you, are there parameters
> that I can adjust to reduce memory requirements? (I have already
> increased the characteristic length to an extreme to minimize the
> surface facet count on the outer box)
> 4) How can I help to address the memory management issue - I have the
> source code and I am able to compile it on linux?
> As a separate but somewhat related issue:
> 5) Why did you remove the experimental STL re-mesh feature of Gmsh
> v1.61. It seems to be a very useful tool, I am curious if there are any
> specific problems with it?
It was not robust enough. We are working on a replacement.
> Thank you again for the great value you make available for free. I hope
> to use and help improve Gmsh, so that medium size, but realistic
> problems can be handled in the realm of CFD.
> Sincerely yours,
> Cem Albukrek, Ph.D.
> Senior Aerodynamics Consultant,
> Software Product Manager
> Tel: (857) 234-1035
> gmsh mailing list
> gmsh at geuz.org
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
More information about the gmsh