On 13 Mar 2013, at 20:31, Christophe Geuzaine <[email protected]> wrote:
> > Hi Johannes, > > Indeed: the problem comes from the "Line in Surface" command, which is still > a bit experimental. (more precisely, we don't yet ensure that the conditions for the blossom algorithm to succeed are satisfied with these embedded lines) > > For your geometry you should really define two surfaces ; that would be more > "natural". Attached is an example. > > Christophe > > <tip.geo> > 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 > > > -- 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
