[Gmsh] bad orientation

Ugis Lacis ugis.lacis at gmail.com
Fri May 15 09:44:28 CEST 2020


Hi Jose,

In general, You should be careful with mesh formats and element types 
when using GMSH and FreeFEM++. I checked your geo file and modified the 
mesh format and version definition (see attached files). I tested the 
geo file by producing the mesh using
"gmsh pentagono.geo -3"
And then loaded and displayed the mesh with FreeFEM++
"FreeFem++ test_load.edp"

Seemed to work fine for me. I use FreeFEM 4.1, and GMSH v4.3.0.

Overall, these questions might be more suitable for FreeFEM mailing list 
/ forum.

/Ugis

On 15/05/2020 08:55, Jose Juan Alonso del Rosario wrote:
> Dear Ugis and colleages of GMSH,
>
> Thank you for your suggestions. I have changed the loop orientation of 
> the upper and lower faces of the pentagon and the whole volumen was 
> meshed (no hole at the end). In addition the same error still happens.
>
> "read mesh ok 0Mesh3, num Tetra:= 24011, num Vertice:= 5665 num 
> boundary Triangles:= 6078
> Mesh3::meshS, num Triangles:= 6078, num Vertice:= 3039 num boundary 
> Edges:= 354
> read mesh ok 0Mesh3, num Tetra:= 24011, num Vertice:= 5665 num 
> boundary Triangles:= 6078
> Mesh3::meshS, num Triangles:= 6078, num Vertice:= 3039 num boundary 
> Edges:= 354
>  Bad orientation: The adj border element  defined by [  3 210 ]  is 
> oriented in the same direction in element 3519 and in the element 367 
> ****** bug in mesh construction? orientation parameter?
> S, num Triangles:= 6078, num Vertice:= 3039 num boundary Edges:= 354
>  Bad orientation: The adj border element  defined by [  3 210 ]  is 
> oriented in the same direction in element 3519 and in the element 367 
> ****** bug in mesh construction? orientation parameter? "
>
> This is after several Optimize3D and Optimize 3d with NetGen and 
> reading it with freefem++
>
> I include the .geo code. It is a thick slice with a pentagonal hole. 
> The gmsh is now 4.5.6 and the meshing options are MeshAdapt and 
> Frontal. I have played with the signs of plane surfaces 14 and 15.
>
> Thanks in advance!!!
>
> Jose
>
>
>
>
>
> El jue., 14 may. 2020 a las 13:54, Ugis Lacis (<ugis.lacis at gmail.com 
> <mailto:ugis.lacis at gmail.com>>) escribió:
>
>     Dear Jose,
>
>     I think I have had similar error, when importing GMSH mesh into
>     FreeFEM++, few years ago (although it seems that the error message
>     might have changed). It turned out that the direction of loop
>     definition in GMSH was the issue for me. See below my exchange
>     with FreeFEM++ mailing list.
>
>     Maybe it can be helpful for you.
>
>     Best regards,
>     Ugis Lacis
>     Researcher
>     KTH Mechanics
>
>     ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>     -------- Forwarded Message --------
>     Subject: 	Re: [Freefempp] Issue with loading mesh from GMSH.
>     Date: 	Fri, 3 Aug 2018 09:41:29 +0200
>     From: 	Uģis Lācis <ugis.lacis at gmail.com>
>     <mailto:ugis.lacis at gmail.com>
>     To: 	FreeFem mailing list <freefempp at ljll.math.upmc.fr>
>     <mailto:freefempp at ljll.math.upmc.fr>
>
>
>
>     Hi everyone,
>
>     I managed to solve the issue myself. It turned out that the
>     direction of GMSH loop was surviving till FreeFEM++ and while GMSH
>     did not complain about anything, FreeFEM++ couldn't use the mesh.
>     mesh2 could be fixed by changing signs in all lines within the
>     line loop, i.e.,
>     change
>     Line Loop(5) = {18, 19, 20, 12, 7, 8};
>     to
>     Line Loop(5) = {-18, -19, -20, -12, -7, -8};
>
>     Maybe this helps to someone at some point.
>
>     Best,
>     Ugis
>
>     On 02/08/18 15:30, Uģis Lācis wrote:
>     Dear FreeFEM++ users and developers,
>
>     I have run into an issue which I am unable to solve by myself. I
>     have been using FreeFEM++ together with GMSH without any problems
>     for quite some time. Now, however, trying to load a 2D mesh
>     generated by GMSH, gives me following error:
>
>     Assertion fail : (area>0)
>         line :281, in file ./include/fem.hpp
>
>     I attach the corresponding geo and msh files of two meshes (mesh1
>     - working fine, mesh2 - does not load), as well as edp file for
>     reading and plotting the mesh.
>
>     I have carefully checked that physical tags are applied correctly,
>     I have tried exporting both in MSH and MESH (medit) formats, using
>     GMSH versions 3.06 and 2.16.0, as well as using FreeFEM++ versions
>     3.560000 and 3.610002, all try has led me to the same behaviour. I
>     have identified that the issue comes from the surface mesh, if I
>     export only line mesh (comment out "Physical Surface(11) = {3,4};"
>     from mesh2.geo and run "gmsh -2 mesh2.geo"), then it loads fine.
>     But checking the mesh within GMSH, everything seems to be
>     perfectly fine...
>
>     Do you have any suggestions on how to solve this issue?
>
>     Best regards,
>     Ugis Lacis
>     Researcher
>     KTH Mechanics
>     ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
>     On 14/05/2020 12:03, Jose Juan Alonso del Rosario wrote:
>>     Dear colleages
>>
>>     I am trying to build the mesh for a slice with a pentagonal hole.
>>     GMSH runs properly with good quality tets but when trying to read
>>     it from freefem++ the error is:
>>
>>     " Bad orientation: The adj border element  defined by [  16 246 ]
>>      is oriented in the same direction in element 3922 and in the
>>     element 446 ****** bug in mesh construction? orientation parameter?
>>       current line = 12 mpirank 1 / 2
>>     "
>>     Can you give any advice on this?
>>
>>     Thanks in advance
>>
>>     Jose
>>
>>     -- 
>>     Prof. Dr. Jose Juan Alonso del Rosario
>>     Applied Physics Dept.,
>>     Naval and Oceanic Engineering.
>>     University of Cadiz.
>>     Avda Rep Saharaui s/n. Puerto Real, 11510, Cadiz, Spain
>>     Tlf: +34 956 016054
>>     Fax: +34 956016079
>>     Secretary: +34 956016078
>>
>>     "All I wanna say is that they don't really care about us",
>>     Michael Jackson
>>
>>     _______________________________________________
>>     gmsh mailing list
>>     gmsh at onelab.info  <mailto:gmsh at onelab.info>
>>     http://onelab.info/mailman/listinfo/gmsh
>
>
>
> -- 
> Prof. Dr. Jose Juan Alonso del Rosario
> Applied Physics Dept.,
> Naval and Oceanic Engineering.
> University of Cadiz.
> Avda Rep Saharaui s/n. Puerto Real, 11510, Cadiz, Spain
> Tlf: +34 956 016054
> Fax: +34 956016079
> Secretary: +34 956016078
>
> "All I wanna say is that they don't really care about us", Michael Jackson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://onelab.info/pipermail/gmsh/attachments/20200515/4e9e5db2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pentagono.geo
Type: application/vnd.dynageo
Size: 1892 bytes
Desc: not available
URL: <http://onelab.info/pipermail/gmsh/attachments/20200515/4e9e5db2/attachment.geo>
-------------- next part --------------
// Level of output                                                                                                    
verbosity = 0;

load "msh3"
load "gmsh";
load "medit";

mesh3 Th3I=gmshload3("pentagono.msh");

fespace Uh (Th3I,P1);

medit("test",Th3I);


More information about the gmsh mailing list