Hi Johannes, Indeed: the problem comes from the "Line in Surface" command, which is still a bit experimental.
For your geometry you should really define two surfaces ; that would be more "natural". Attached is an example. Christophe
tip.geo
Description: Binary data
On 13 Mar 2013, at 15:30, Johannes Reinhardt <[email protected]> wrote: > Hi, > > sorry, that was unfortunate: I had accidentally attached the case for dist = > 2.1, which works also here. For larger dists (e.g. 3.5) it fails, see new > attachment. > > It fails with all the triangulation methods, and the resulting triangulation > always shows weird artifacts (see attached screenshot), but at different > places depending on the triangulation method. > > Thank you for your rapid answer > > Johannes > > > On 03/13/2013 02:11 PM, Christophe Geuzaine wrote: >> >> Hi Johannes, >> >> That's weird - it seems to work fine over here (cf screenshot). I will test >> it on our Linux machine when I have the time. >> >> Does it happen with all the triangulation methods (MeshAdapt, Delaunay, >> Frontal, Delaunay for quads)? >> >> >> Christophe >> <Mail Attachment.png> >> >> On 13 Mar 2013, at 13:32, Johannes Reinhardt <[email protected]> >> wrote: >> >>> Hello everybody, >>> >>> first I want to thank everybody involved in the development of gmsh. It is >>> a really great tool and has helped me a lot in my research. >>> >>> However I run into a probem when I try to create a 2D quad mesh with the >>> outline of two superimposed disks embedded. However Blossom almost always >>> fails with the message: >>> >>> Warning : Perfect Match Failed in Quadrangulation, Applying Graph Splits >>> >>> printed 10 times. I attached a simple geometry file that shows this problem. >>> >>> For small distances (e.g. dist=2.1) this problem does not occur, but for >>> larger distances (and these are the ones that I want to study), I always >>> get this error. >>> >>> For other geometries where I had this problem, playing a bit with the mesh >>> element sizes helped, but I could not find good numbers for this case. I >>> also tried both DelQuad and MeshAdapt as Meshing Algorithms, but I always >>> get the error above. >>> >>> I briefly looked at the Blossom Quad publication, but could not find any >>> explanation for this behaviour. My best guess is, that the embedded curve >>> conflicts with a perfect matching, and the extra edges mechanism fails in >>> this case. >>> >>> I tested both gmsh 2.6.1 compiled from source and the precompiled gmsh >>> 2.7.0 Linux 64bit binary on Ubuntu 11.10, both show the same behaviour. >>> >>> Has anybody an idea how to reformulate the geometry description to avoid >>> this problem? >>> >>> Thanks in advance and greetings >>> >>> Johannes >>> <tip.geo>_______________________________________________ >>> gmsh mailing list >>> [email protected] >>> http://www.geuz.org/mailman/listinfo/gmsh >> >> -- >> Prof. Christophe Geuzaine >> University of Liege, Electrical Engineering and Computer Science >> http://www.montefiore.ulg.ac.be/~geuzaine >> >> >> > > <Screenshot at 2013-03-13 > 15:22:24.png><tip.geo>_______________________________________________ > gmsh mailing list > [email protected] > http://www.geuz.org/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://www.geuz.org/mailman/listinfo/gmsh
