[mörli]

Hi everyone,


I know this is a well discussed topic in this forum but I have not found an answer on my question so I hope you can help:


I was wondering how OpenFOAM "decides" whether it is dealing with a sturctured or unstructured mesh. I read in a textbook structured is much easier to handle as the belonging neighbours, faces, etc don't have to be stored as they are kind of defined by the structure of the mesh. Furthermore I understood at least when having structured mesh with same cell size (and optimally of hexahedral) the volume and area calculation for integral is much easier as well as interpolation due to orthogonality. (I know I am probably mixing definitions of structured and regular mesh here, but the question stays the same: how does OpenFOAM "know")

Nevertheless even for the simpliest blockMesh neighbour, faces, ... files are stored. So my question is if they are used for calculation anyhow and even a structured mesh is considered unstructured by OpenFOAM or if somehow in the files is defined how to handle the data which can be read by the code.


Furthermore I read about hybrid meshes. This would mean the files need to provide information how to handle the mesh for given areas of the mesh.


What about the refineHexMesh tool (for local refinement)? I assume it is generating structured meshes (starting from structured of course). Does this mean the whole "numbering" is rearranged? And what about the "transition" area. I guess the system of neighbouring cells is different from the rest of the mesh. How is this dealt with?




Thanks a lot in advance for any answer.

[akidess]

There are no structured meshes in OpenFOAM. Everything is unstructured, which is the most general way of doing things.

[mörli]

Thanks a lot for the fast reply.


Is there still any advantage of using blockMesh build meshes instead of for example snappyHexMesh build ones? I guess the orthogonality criterium is easier to handle but is there anything else?


I am especially thinking of using actuator line oder disk models instead of full meshes for representation of a turbine. Of course the mesh for full mesh needs to be much finer around the blades for a full mesh solution, but I always thought the structured uniform blockMesh grid has further advantages which I can't really give reasons for if OpenFOAM is handling the meshes as unstructured anyway.

[akidess]

blockMesh is very fast, and gives you much more control over the mesh than snappyHexMesh.

[louisgag]

Hi Anton,
I agree, but do you know of tutorials that use blockMesh to mesh a non-basic geometry in 3D?
Regards,

[akidess]

Originally Posted by louisgag

Hi Anton,
I agree, but do you know of tutorials that use blockMesh to mesh a non-basic geometry in 3D?
Regards,

What is "non-basic"? Perhaps the heatExchanger tutorial fits the bill. Check chtMultiRegionFoam.

[louisgag]

Thanks for this hint, I looked it up (and also found a nice windshield example).
However, I was thinking more in the lines of aircraft fuselage or wings, or something like the motorbike tutorial. It would take a lot of patience to convert the motorbike stl into vertices that could be used by blockMesh.

[akidess]

Nobody in their right mind would try meshing something as complex as a motorbike with blockMesh (or any other structured mesher IMO)

[akidess]

For a fuselage, you could snap your blockMesh to vertices of an STL using community tools:

http://www.etudes-ng.net/home/development/extBlockMesh

[louisgag]

Thanks for sharing this link, the software does look interesting indeed.


However, it requires an old OpenFOAM version (which is not such a big issue) but, more importantly, it does not mesh boundary layers, which would be the reason I was considering to use blockMesh.