Export/import issues format Salome/gmsh/OpenFOAM [solved]

1

Hello,
I am trying to import my meshes generated in salome to OpenFOAM.
the meshes have different type of cells (including pyramids, so I can not use the UNV format), therefore I try to export the mesh generated in salome to gmsh, and from gmsh export it to OpenFOAM. Nevertheless, I have not successfully got a ‘working’ mesh.
I have tried different possible exporting formats from salome to then import them into gmsh:
med 4.1, 4.0, 3.3, 3.2
CGNS (wich gave an error in gmsh 4.11.1)
GMF ASCII, binary (binary gave an error in gmsh 4.11.1)
when I import it to gmsh I don’t get any error message (with exception of the CGNS and GMF binary. then I export from there into .msh version 4.1 and then import it into OpenFOAM using gmshToFoam. this “works” but when I look at the mesh in paraview it is wrongly connected. It might be a stretch but depending in the format I exported in salome, I get different results in the end that’s why I am publishing here among the gmsh bug issues (not sure if the issue comes from the writing or reading this formats)
gmshBugReport
any insight in this issue or how to solve it would be appreciated

Edit:
the correct workflow for importing a med file to Openfoam (in case that anyone finds with similar issue) would be: In Salome

  1. Create the 2D groups for patches and at least one 3D group that contains all the cells, also it is important to delete all 1D groups (not sure if the 0D also) of the mesh, so only have surface and volumetric groups.
  2. Export it in med file format, from my tests whatever version is ok
  3. Import the mesh in gmsh by open/select the med file
  4. Go to file export
  5. Export it using following parameters ASCII 2.1 format, and all options set to off
  6. Use gmshToFoam without any flag. This will allow to conturnate the issue of not being able to export directly meshes with pyramids from Salome in a format that is importable to openfoam
1 Like
2

Hi franco.ota, thank you for the workflow reported. It also worked for me using SALOME 9.14, OpenFOAM 13 and Gmsh 4.12.

To follow your workflow I needed, previously, to add MED support to Gmesh as follows (done by IA, with corrections):

Update & install build deps (first block installs MED & HDF5 dev packages)
sudo apt update
sudo apt install -y build-essential cmake git pkg-config
libmed-dev libmedc-dev libmed11 libhdf5-dev
libx11-dev libxext-dev libgl1-mesa-dev

(Optional extras you may need for full Gmsh features)
sudo apt install -y libglu1-mesa-dev libfltk1.3-dev libjpeg-dev libpng-dev

2) Download Gmsh 4.12 source (pick 4.12.2 or 4.12.1 if you prefer)
cd /tmp
wget https://gmsh.info/src/gmsh-4.12.2-source.tgz
tar xzf gmsh-4.12.2-source.tgz
cd gmsh-4.12.2-source

3) Create build dir and run CMake enabling MED
mkdir build && cd build

Try a normal configure first — MED is an optional CMake option named “MED”
cmake .. -DMED=ON

4) Build & install
make -j$(nproc)
sudo make install

After it finishes, test MED support with:
gmsh -help | grep med

P.S.: In my case, I created a mesh in SALOME 9.14 that included pyramids. I then used the “Split Volumes” tool to split these pyramids into tetrahedra for export as a .unv file. Unfortunately, this splitting process causes ideasUnvToFoam to create a defaultPatch in OpenFOAM (which is not visible in SALOME) at the locations where the pyramids were split. In my case, the pyramids were formed at the interface between the hexahedral and tetrahedral cells.**

3

@franco.ota

Hi, thank you for your great contribution. That’s outstanding. I think that MED to OpenFOAM procedure should be updated.

  1. Create one 3D group for each partition that contains all cells of it. Never include overlapping groups. For example, activating Viscous Layer group creation. Create 2D patches for OpenFOAM. 1D groups do not play role. If no group is created, converter takes default names.

  2. Export it in MED 4.1 file format in Salome 9.15.

  3. Import the mesh in GMSH 4.15.2 by open/select the MED file

  4. Go to file export

  5. Export as ASCII 2 format, and all options set to off

  6. Use gmshToFoam without any flag

In the example, I partitioned a geometry into two volumes.

example_box_pyramid_OF.hdf (280.9 KB)

SalomeMesh1 has tetrahedrons, pyramids and prism volume elements. Partitioned into two.

SalomeMesh1
SalomeMesh11532×662 86.8 KB

SalomeMesh2 has single volume

SalomeMesh2
SalomeMesh21337×737 54.3 KB

Here are OpenFOAM checkMesh outputs:

checkMesh_1a
checkMesh_1a722×672 13.8 KB

checkMesh_1b
checkMesh_1b1207×600 24.2 KB

checkMesh_2a
checkMesh_2a612×667 11.6 KB

checkMesh_2b
checkMesh_2b1087×605 20.8 KB

One can try and test adding Viscous Layer and/or 1D groups. Behavior is different from UNV conversion.

4

I dont see the necessity of 1D groups for OpenFOAM, so i dont care about them. going thought gmsh is a pain IMO, currently i am not using mixed element meshes therefore i dont dig too much into this. UNV is more than enough.
that being said, if you have small meshes as the one you posted you can use the following code:

which exports directly into foam, i re writed my own mesh parser to be faster but this one for small meshes is more than enough. also as a side note:

  1. it looks like they added pyramids export to UNV in the newer version, i dont compile from source but it looks like maybe with 9.16 this might get solved.finally. UNV format: export pyramids to 312. Import from 119 and 312 · SalomePlatform/smesh@0c20bfd · GitHub
    if thats the case, i highly recommend to stay there. the I/O will be a big bootleneck when your mesh is large.
  2. simvia, which is part of edf (which it develops salome) have forked meshio and they mention that in the future they will add OpenFOAM support, in the begining for reading meshes not exporting but hope it will improve in the future GitHub - simvia-tech/meshio: 🕸 input/output for many mesh formats · GitHub