> On 11 Apr 2019, at 18:22, Nathan RICKS <[email protected]> wrote: > > Sorry for the repeated messages, just trying to sort out the issue and coming > across new things/information that might help resolve the issue. In the .geo > file attached, it demonstrates what "I think" is the cause of my errors - if > you generate the 2D mesh and look at the trailing edge, there are cells/nodes > crossing over the lines/edges where they obviously shouldn't be. This occurs > on both Mac and Linux for me at least. Have you seen this issue before by any > chance? >
It seems that you ran into a case where the small random perturbation we use in our 2D initial triangulation is too large. A new version of the algorithm without any such perturbation will be available in a future release; but in the meantime you can set e.g. "gmsh -rand 1e-12" (or set Mesh.RandomFactor = 1e-12 in your script), which seems to solve the issue. Christophe > Thanks again, > > Nathan Ricks > VUB > > > > > > From: Nathan RICKS > Sent: Thursday, 11 April 2019 11:41 AM > To: Christophe Geuzaine > Cc: [email protected] > Subject: Re: [Gmsh] Errors when increasing NNodesByEdge on a small edge > > I'm not sure if this helps determine the issue, but it seems if I generate > the mesh using the Delaunay algorithm, there are cells that break through > boundaries of the surfaces, and if I use Frontal-Delaunay (which I was) these > correspond to the broken cells shown in the first screenshots. I've attached > two screenshots showing this, if you compare between the two you can see > "correspondence of errors". > > From: Nathan RICKS > Sent: Thursday, 11 April 2019 9:00 AM > To: Christophe Geuzaine > Cc: [email protected] > Subject: Re: [Gmsh] Errors when increasing NNodesByEdge on a small edge > > Dear Prof. Geuzaine, > > Thanks for the response. Indeed, I just tested this using Gmsh on my Mac, and > the resultant mesh runs fine. > > So it seems the problem is restricted to the workstation, which is running > Linux 64-bit (red hat). I just tried instead compiling from the source code > and the error persists there also unfortunately. Are you aware of anything > that may cause this? It's for an optimisation routine, so thousands of meshes > are generated, so using my Mac isn't feasible unfortunately. > > In regards to the boundary layer, I was originally using the BL field > directly, however ran into issues as I couldn't have a growth rate "around" > the airfoil spline (to have narrower cells at leading and trailing edges), as > well as perpendicular to the airfoil. Also, at the trailing edge using the > fan node resulted in too small cells causing numerical errors, and without it > the cells were too bad quality, also causing errors. Using the transfinite > surfaces gave me flexibility in the boundary layers, allowing two different > growth rates perpendicular to the surface. With that it was running very > well, until now on trying to include the blunt TE. > > Thank you again, > Kind Regards, > > Nathan Ricks. > > > > > From: Christophe Geuzaine <[email protected]> > Sent: Thursday, 11 April 2019 12:09 AM > To: Nathan RICKS > Cc: [email protected] > Subject: Re: [Gmsh] Errors when increasing NNodesByEdge on a small edge > > > > > On 10 Apr 2019, at 21:57, Nathan RICKS <[email protected]> wrote: > > > > Hi all, > > > > I have quite a particular problem, but I'm hoping someone can help. I'm > > meshing an airfoil using transfinite surfaces in the boundary layer. > > > > I've just had to add a blunt trailing edge (mesh was working well with > > sharp trailing edge) to the airfoil, and now I have this one error stopping > > me, and I just can't figure it out... > > > > When I increase the NNodesByEdge on Field[11] from 6 to 15, the mesh ends > > up bad quality, with cell corners not matching other cells at the boundary > > of surfaces, and it causes SU2 to diverge instantly. It runs fine with 6, > > but crashes at 15. I've attached two images showing that it is a mesh issue > > causing this (nothing else is being changed in the setup). > > > > I cannot seem to reproduce the issue on my Mac. Attached is the mesh > generated on your .geo file: > > > > Other things such as reducing lcMin on Field[12] can also make it crash for > > example, however the above has visible errors in the mesh. > > > > Idem... What OS are you running on? > > PS: instead of generating the BL by hand, why not using the boundary layer > field directly? Cf. e.g. > > https://gitlab.onelab.info/gmsh/gmsh/blob/master/benchmarks/2d/naca12BL.geo > https://gitlab.onelab.info/gmsh/gmsh/blob/master/benchmarks/2d/naca12_2d_trailing.geo > > > Does anyone have an idea on why I can't use the Distance/Threshold field as > > normal on this edge? > > > > If you can provide any guidance that would be greatly appreciated, it's so > > close...! I've already tested with the latest release with the same results. > > > > Thanks a lot, > > Kind Regards, > > > > Nathan Ricks > > > > > > > > > > > > <NNodes_15.png><NNodes_6.png><airfoil_level1.geo>_______________________________________________ > > 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 > > > > <airfoil_level1_edit.geo>_______________________________________________ > 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
