[Gmsh] Problem with mesh creation from a brep geometry

[Christophe Geuzaine]

> On 14 Dec 2019, at 21:36, andrew <armitatz at gmail.com> 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: n.geo
Type: application/octet-stream
Size: 2215 bytes
Desc: not available
URL: <http://onelab.info/pipermail/gmsh/attachments/20191215/563c21a1/attachment.geo>
-------------- next part --------------



> 
> ???? ???, 14 ??? 2019 ???? 10:35 ?.?., ?/? andrew <armitatz at gmail.com> ??????:
> 
> 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
> gmsh at onelab.info
> http://onelab.info/mailman/listinfo/gmsh

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