[Gmsh] Error due to many volumes

Romain Quey quey at emse.fr
Mon Jun 16 09:10:26 CEST 2008


Christophe - Yes, it only happens with Netgen.

Quoting Christophe Geuzaine <cgeuzaine at ulg.ac.be>:

>
> Werner, Romain - I think I might understand where the problem comes  
> from: does it only happen with the Netgen algorithm?
>
>
>
> magpar wrote:
>> Dear Romain,
>> Dear Gmsh developers and users,
>>
>> I can confirm Romain's problem and his solution:
>>
>> http://www.geuz.org/pipermail/gmsh/2008/003316.html
>>
>>>> Romain Quey wrote:
>>>>> Dear Gmsh developers, dear all,
>>>>>
>>>>> Using gmsh 2.2.0 on Linux, I'm having the following error:
>>>>>
>>>>> $ gmsh -3 n1100-id1.geo
>>>>> Info    : Parsing file 'n1100-id1.geo'
>>>>> Error   : [on processor 0] Unable to open file 'n1100-id1.msh'
>>>>>
>>>>> My geo file contains many 'Volume' definitions (1100) -- see the  
>>>>>  attached example.
>>
>> [...]
>>
>>> You are right, the bug does not occur here, but when writing the mesh.
>>>
>>> However, I think the reason for the bug is really this one: when
>>> increasing the max number of openable files per process on my system
>>> (from 1024 to 1000000), I can successfully mesh the file.  I think that
>>> if you run 'ulimit -n 1024' on your system, gmsh will crash too.
>>
>> I observed similar problems with models with many volumes a while  
>> ago and reported them on the gmsh mailing list:
>>
>> http://www.geuz.org/pipermail/gmsh/2007/002946.html
>> http://www.geuz.org/pipermail/gmsh/2007/002831.html
>> http://www.geuz.org/pipermail/gmsh/2007/002826.html
>> http://www.geuz.org/pipermail/gmsh/2007/002947.html
>> http://www.geuz.org/search/search-geuz.cgi?q=magpar&ul=%2Fpipermail%2Fgmsh%2F&ps=10
>>
>> Based on Romain's observation I tested his solution to increase the  
>> resources (max. number of open files) on the shell and I can  
>> confirm that this fixes my problems, too.
>>
>> Here is an example (from one of my earlier posts) which exhibits  
>> the problem (mesh generation is successful, but the msh file cannot  
>> be saved):
>> http://www.geuz.org/pipermail/gmsh/attachments/20071214/5a438bd7/attachment-0005.gz
>>
>> To make this increase in the resources permanent one has to modify  
>> the limits in /etc/security/limits.conf by adding or modifying the  
>> line
>>
>> *                hard    nofile          10000
>>
>> After that it is necessary to login on a new shell or even reboot  
>> the machine because new processes inherit this setting from the  
>> process/shell which launches it.
>>
>> So, finally the question is why gmsh keeps so many files open (one  
>> for each volume!?) and how this could be fixed.
>>
>> Thanks for the useful discussion and help on this mailing list  
>> which fixed my problem, too!
>>
>> Werner
>>
>
>
> -- 
> Prof. Christophe Geuzaine
> University of Liege, Electrical Engineering and Computer Science
> http://www.montefiore.ulg.ac.be/~geuzaine
>



-- 
Romain QUEY, Doctorant (bureau H3-05)
Ecole des Mines de Saint-Etienne
Centre SMS
Laboratoire PECM - UMR CNRS 5146
158 cours Fauriel
42023 Saint-Etienne, cedex 2
Tel. 04.77.49.97.38 - Fax. 04.77.42.66.78
E-mail : quey at emse.fr
http://www.emse.fr/~quey
http://sourceforge.net/projects/orilib

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.