code_saturne User's Forum

Hello everybody.

I've been using Gmsh for a while to mesh with hexaedra around an airfoil, using transfinite, extrude and recombine algorithms. I never had a problem, but given the way in which the space discretization is made, I would like to know if I there is some way of creating unstructured hex meshes by means of the same algorithms, in order to lower a bit the element quantity (my PC is not exactly a great number cruncher). Choosing plainly a tet algorithm and then setting "all hexas" in the GUI is not a choice. I tried setting different nodal discretization on two opposing sides of a same transfinite surface but Gmsh says that cannot be done, that dimensions should match. So on that surface the transfinite algorithm is not applied and that part gets an unstructured tet mesh.

If you look at the image attached, volumes 1, 2, 7 and 8 are the ones I want to keep fine meshed for obvious reasons, and the rest should be relatively coarse like volumes 5, 6, 9 and 10 (the last two are the big green and yellow areas). However, due to an apparent limitation of Gmsh's transfinite surface algorithm I cannot reduce the streamwise discretization of volumes 3 and 4. I only need the refinement around the airfoil and its wake, the rest of the flow is little pertubed. I was thinking of superimposing new identical ellipse lines with different discretization over the existing ones between volumes 1&3 and 2&4, so in that way I would get what I want, but the volumes are not going to be connected (except for individual points). Would that be an issue? Are there alternative solutions? I'm providing also the .geo script. Thank you in advance. César
 
PD: I know the meshing seems odd, I did it on purpose to investigate an alternative way in order to lower the necessary elements.

Hello,

I am not a Gmsh expert (I am not too comfortable with its GUI, and never invested enought time to master its scripts), and I am a little bit more comfortable with SALOME's mesher ( http://www.samome-platform.org ), though its ergonomy could also be improved.

In any case, if I understand correctly, you have a mesh with hanging nodes or non-conforming elements.  With Code_Saturne, you can preprocess that type of mesh using the Preprocessor's mesh joining functionality (which can be used both to join separate mesh files or non-conforming faces from a single mesh). If you have physical group numbers in Gmsh assigned to lines between volumes 1&3 and 2&3, I would recommend using those group numbers as color numbers in the selection criteria for mesh joining, otherwise use you may let it default to selecting the whole boundary (which will take a bit more time).

You may thus test mesh joining either through the GUI's mesh quality criteria page, or running:
code_saturne check_mesh -m <mymesh.msh> -j --color <non-conforming physical group numbers>

or simply:
code_saturne check_mesh -m <mymesh.msh> -j

You may also run the Preprocessor only, using cs_preprocess instead of code_saturne, but then you also need to an an --ensight option to obtain output you may postprocess.
Note that joining non-conforming meshes will most often lead to polyhedral elements which are neither hexahedra, not pyramids, prisms, or tetrahedra, and that most versions of ParaView will lead to visualization artifacts in those areas (false boundary faces), but ParaView 3.8.0 seems to have a bug when those elements are present (I have not tested with 3.8.1). The current development version (3.9, for 3.10) adds true support for those polyhedra, but as it is not released yet, it must be downloaded as source using git and then compiled.

If instead of using ParaView or VisIt, you use SALOME's VISU package, polyhedra are handled similarly to ParaView prior to 3.9, but the GUI will become very slow if you have many cells of that type.

Best regards,

  Yvan