code_saturne User's Forum

Hello:
 
I made a Gmsh script to generate a mesh around a delta wing with biconvex airfoil sections. This mesh is almost fully hexahedral as it has been generated with extrusions and Gmsh's transfinite algorithms. My problem is that no matter in which format I save this mesh, Saturne's preprocessor always throws:
 
The mesh has face -> cell connectivity errors. We can go no further.
 
I'm using Code_Saturne 2.0.1 and I've generated the mesh with both Gmsh 2.5.0 and 2.5.1. With both versions og Gmsh I get the same error, so I don't think it's a Gmsh bug. I have used Gmsh previously with Saturne's 2.0beta version and never had this issue (this is the first time I'm using the stable Saturne 2.0). I am aware that Gmsh inverts some surface normals, but using the "--reorient" option didn't change the result.

I'm attaching the .GEO script to generate the geometry and mesh in Gmsh, since the mesh is a bit heavy for uploading. The mesh will be of a bit more than 10^6 elements. To generate it, simply open the script with File->Open and once it's opened press "m" in your keyboard to open the mesh generation menu. Now click on "3D" and wait until the mesh is generated (Gmsh, is not really fast, so it may take a while).

I hope you can help me and point out my mistakes. Thank you very much in advance.

César Vecchio

Hello,

I'm not used with Gmsh but I generated the mesh.

When I use cs_preprocess to view the mesh with Ensight I see that there are some isolated faces (the red one on pic01), that's not good and faces with no attributes (yellow faces on pic02).

As I don't know gmsh I'm not sure that it will help but perhaps you have some problems merging the different parts of your mesh. Did you define all the boundary faces?
 
I'll ask to the Code_Saturne developer if it can be a bug from Code_Saturne.
 
Regards.
 
Matthieu

Hello,
I also just reproduced your error, with 23 faces having 2 cells on a same side. Did you use version 2.0-beta with the same mesh, or is this the firts time you use this mesh ? As Matthieu wrote, I suspect an error in merging in your mesh: as cells are very thin in the area where you have the error (use --ensight, --med, or --cgns for postprocessing output), merging of vertices by Gmsh may have merged a few vertices "inside" the submeshes joined, instead of just at the boundary, leading to overlapping cells. I am not a regular user of Gmsh, so I am not sure if this can happen exaclty in this way, but I suspect something similar, related to the fact that you have very thin cells in this area and Gmsh does automatic merging by default.
I also just tested the piece_extr_rec.geo example from the Gmsh demos (version 2.5.0), and saved it in Gmsh 2.0 format (both ASCII and binary) and had no issues with the Code_Saturne preprocessor, so I suspect the problem is really due to the mesh.
Best regards,
  Yvan

Thank you both for the quick answer. I'm currently looking at that, and yes, it's the very first time I use this mesh. I didn't join any submesh because everything was generated as a whole mesh. Gmsh works in a BREP fashion for the geometry, and for structured meshes it follows the same procedure, so if surfaces enclose the volume there should be no duplication of entities. I have seen this issue appearing at Gmsh's mail list but only when one exports the mesh without defining the so called "physical groups", which I did. Maybe the error is there, otherwise I'll have to look somewhere else in the script.
One interesting data, Gmsh is now capable of direct MED 3.0 export. And now thatI remember, when saving as MED, an error was reported saying that 3 elements where incosistent. The generated mesh, despite being a file with a respectable size, could not be opened in Salome. It seems I have to get my hands dirty, hehe...

Hi again.
Preliminary good news: the problem was indeed Gmsh since it's 2.5.x versions (I'll report it to Gmsh developers), as I tried the very same script with an older Gmsh 2.4 and the generated mesh was exported to MED, UNV and MSH(binary) format. All three of them were succesfully read by the preprocessor. Let's see how this goes now...

I just want to confirm that the problem was indeed Gmsh 2.5.x. My simulation went perfect with the generated meshes under Gmsh 2.4.2.