Quoting Christophe Geuzaine <[EMAIL PROTECTED]>: > > > Romain Quey wrote: >> Christophe - Yes, it only happens with Netgen. >> > > OK. We've uploaded Gmsh 2.2.1, which should fix the problem. Can you > give it a try?
That's OK with this version. Many thanks! > > Thanks, > Christophe > > >> Quoting Christophe Geuzaine <[EMAIL PROTECTED]>: >> >>> 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 >>> >> >> >> > > > -- > Prof. Christophe Geuzaine > University of Liege, Electrical Engineering and Computer Science > http://www.montefiore.ulg.ac.be/~geuzaine > > _______________________________________________ > gmsh mailing list > [email protected] > http://www.geuz.org/mailman/listinfo/gmsh > > -- 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. _______________________________________________ gmsh mailing list [email protected] http://www.geuz.org/mailman/listinfo/gmsh
