> On 14 Dec 2019, at 21:36, andrew <[email protected]> wrote:
> 
> sorry, I forgot to attach the files...
> 

I removed explicit setting of the algorithm and the random perturbation factor, 
and everything seems OK on our Linux, Mac and Windows testing machines with the 
latest dev snapshot (soon to be released Gmsh 4.5). Can you give it a try?

Attachment: n.geo
Description: Binary data



> 
> Στις Σάβ, 14 Δεκ 2019 στις 10:35 μ.μ., ο/η andrew <[email protected]> έγραψε:
> 
> Hi,
> 
> #1.
> I have the file n.geo and a corresponding P.brep file. The n.geo loads the 
> brep file (p.brep) and meshes it using delaunay and fields. In linux gmsh ver 
> 4.4.1 meshes the file using delaunay in less than 3 minutes in an i7. In 
> windows in an i7 the same version does not produce a mesh even after more 
> than 4-5 minutes (it probably falls back to meshAdapt). 
> 
> I solved this problem by increasing the randomFactor but I would expect that 
> the two version would show the same behaviour.
> 
> #2. 
> Is there a way to disable the automatic fall back to meshadapt if delaunay 
> fails even if it means that gmsh will abort with an error?
> 
> #3. 
> The binary version of gmsh for linux is compiled with parallel support (or at 
> least that is what I see in the info). In ubuntu is there a one liner that 
> can run gmsh in parallel for 2d or 3d meshes like 'mpirun -np 4 gmsh -.... 
> -parallel' ?
> 
> kind regards
> 
> andrew tsiantis
> <n.geo><p.png><P.brep>_______________________________________________
> gmsh mailing list
> [email protected]
> http://onelab.info/mailman/listinfo/gmsh

— 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science 
http://www.montefiore.ulg.ac.be/~geuzaine



_______________________________________________
gmsh mailing list
[email protected]
http://onelab.info/mailman/listinfo/gmsh

Reply via email to