GmshToFoam warnings
 

Hello all,

I'm trying to build a mesh in GMSH and send it to OpenFOAM for simulation using their tool gmshToFoam. I've been getting a lot of "warnings" and the result is that two of my patches are not correctly populated (in fact they each own zero faces) and the defaultFaces patch has more than zero.

The warnings are of the type:
-Could not match gmsh face 3(856 858 857) to any of the interior or exterior faces that share the same 0th point
-Not using gmsh face 3(856 859 860) since zero vertex is not on boundary of polyMesh

I've read a former thread in cfd-online and tried to apply it to my .geo file (including everything into a physical group), but haven't been successful.

My experience level with gmsh is pretty low, so I apologize if this is an easy question or something that I should have picked up quickly from the previous thread.

My intention is to create a tube with the shape given in the .geo file, and have air flowing through from one end to the other (inlet to outlet).

Hi,

As your GEO file does not contain commands for mesh creation, can you describe your process of mesh generation? I have tried usuall "Mesh 3" command but did not succeed in generating anything that can be called mesh. Gmsh even rejected to create 3D mesh in central part of the geometry.

I open the .geo file in the gmsh GUI by command line: "gmsh container_full.geo". It loads the .geo file without warning/error and then I do "Modules>Mesh>2D" and "Modules>Mesh>3D", which run without warning/error.

I'm using version 2.8.5 of gmsh.

Hi,

Gmsh version 2.8.5 but under OS X. MSH file generated using attached GEO-file (with commands Mesh 2 and Mesh 3) produces the following output:

Well that's strange, I've been using gmsh in OSX as well. After running the command: "gmsh container_full.geo -2 -3 -o container_full.msh", and then gmshToFoam, I now get:

Interestingly, when I run gmsh in ubuntu (2.8.2) on the same file and then gmshToFoam, I get another different result:

So then perhaps the first question should be: why are we getting different results running this .geo file through gmsh (is the .geo file poorly constructed?).

Perhaps knowing why that is could make gmshToFoam run smoother. Thanks for your help!

Hi,

Guess we have different mesh generation options. I was able to reproduce your error message if I set 2D and 3D algorithms to Frontal. And I don't know how to fix this except to propose to mesh different shapes of the tube using transfinite algorithm (dividing geometry into volumes with 6 corners), then merge meshes (using mergeMeshes) and finally stitch connecting patches (using stitchMesh). Or you can use 2D mesh from Gmsh as STL for snappyHexMesh/cfMesh.

And btw error message on Ubuntu means that gmsh on Ubuntu produced higher-order mesh elements, they are ignored by gmshToFoam with the warning you have posted.

could you give an example of this (Transfinite mesh) for just one section of the tube? I've attached an attempt to do this for one section, and it works well in 2-D, but throws errors in 3-D.

If I understand correctly, I will also have to also:
-label the boundaries of each section (e.g. inlet, walls1, innerSurface1a; innerSurface1b, walls2, innerSurface2a; etc.)
-run each section through gmshToFoam individually
-merge mesh
-stitch adjoining patches

whew! shame it can't be easier. Is the unstructured mesh insufficient for OpenFOAM - why is transfinite needed?

Hi,

See an example of transfinite mesh of the middle part (tube) attached to the message. Other parts (frusta and spherical sectors) are made the same way, frusta just have different top and bottom circle radii, spherical sectors have curved outer edges.

Yes, you get the algorithm right. Also, as I said, you can take 2D surface mesh as STL and use snappyHexMesh to create volume mesh.

It is sufficient but a) with high probability Gmsh will generate mesh with high non-orthogonality, b) you've got more control over mesh quality when using transfinite algorithm, and c) do you have unstructured mesh?

Hi,

Finally I was able to convert your geo-file into msh. You've forgotten to create geometrical volume for tube part, so no 3D mesh were generated for that part and this somehow worried gmshToFoam.

After I was able to identify parts of the mesh that gmshToFoam do not like, it is on attached image. There are lots of planes on the picture, during conversion all of them, except the surface of the cone, are ignored. Are these planes really there?

That set of planes (and the same on the other side) are there as "construction planes" or "scaffolding". That's to say that I needed to make them to construct the object, but I they are not part of the finished object.

I really don't need them meshed and I would prefer that openFOAM doesn't know about them at all.

Your tube.geo file is great, thanks!! and it passes gmshToFoam and simulates nicely.

Why should I not just do everything like this in one big .geo file, so that way my mesh is already merged and my surfaces already stitched?

Well,

You don't need these planes and yet, you created physical group for these planes (which then will be converted into patch, so OpenFOAM will definitely know about these planes). So you can start by removing physical group "construction". Then you need to create geometrical volumes for these "construction cones". Currently they are not meshed. And finally inlet and outlet planes meshed twice, though I wasn't able to find a reason for this behaviour. Maybe they are created in the base geometry and then during extrude operation.

I proposed to mesh different parts of the mesh separately so it will be easier to manage geometry or the parts. Also it will be easier to control density of the meshes in different parts of the shape if you mesh parts separately. If it is OK for you to deal with the whole geometry in a single geo-file, you can mesh the whole shape at once.

Thanks again for your guidance Alexey, things are working well!

For any readers curious to how I solved my issues, here's what I did:
1. adapted Alexey's tube.geo file that uses transfinite meshing and applied this to the inlet and outlet sections
2. adapted this .geo file to mesh the hemi-spherical sections (defining all the lines and planes individually, rather than by extrusion/rotation).
3. labeled all the exterior sections as physical surfaces (i.e. "walls", "inlet", outlet")
4. labeled all the interior sections as physical surfaces ("interface1a", "interface1b", ...)
5. ran all with gmsh to make .msh files.
6. created separate folders for each part in my openfoam project directory
7. copied in project parameter folders (OpenFOAM sees each part as it's own simulation)
8. did gmshToFoam to each part
9. merged the meshes (only two at a time: i.e. part1 & part2, part1 & part3, ...
10. stitched the meshes across the interface patches

Voila! Done! I have a working object with a combined exterior and no interior patches. For more specifics on using mergeMeshes and stitchMesh, see: http://openfoamwiki.net/index.php/Si...vaned_diffuser

:)

gmshToFoam error: 'Unhandled element at line '
 

Thanks for pointing that out. But what would be the right path to solve this, to get rid of higher order elements while meshing in Gmsh (don't know if it's possible...)? Or, any other ways to import mesh to openFOAM?

I actually use Gmsh because there is a possibility to automate the mesh generation procedure till running simulation. Which I am exploring right now and faced the 'Unhandled element at line ' issue, where all my boundary patches are lost while invoking gmshtofoam ).

Please inform if anybody knows if there are other ways (keeping the non-gui or command line pathway in mind).

Thanks in advance,