Meshing with OpenFOAM
Before running any CFD simulations we need to generate a mesh around our geometry to perform calculations on. This page is meant to document the standard process we use to generate this mesh for ARIS rockets.
Inputs:
- Geometry exported from some CAD software in named STL format.
- The sample OpenFOAM case folder (ofcase_heidi_fullbody_meshing)
Outputs:
- 3D mesh conforming to the STL surfaces input, generated with snappyHexMesh
Before starting
Download the example OpenFOAM case folder from the EULER CFD repo and read through the OpenFOAM v4 user guide sections for BlockMesh and SnappyHexMesh.
Requirements
- OpenFoam v4.x
- MPI for parallel runs
- GNU Make for automated mesh generation
Automated run with GNU Make
The process has been automated with a Makefile
in the case directory, which offers the following commands
$ make # Run blockMesh, snappyHexMesh, etc.
$ make check # Run checkMesh to check mesh quality
$ make clean # Remove processor* folders, meshes etc.
$ make rmprocs # Remove just processor* folders
The Makefile
will also create a log/
folder and pipe the outputs of each OpenFOAM command into logfiles to aid in debugging.
Since snappyHexMesh
can be quite computationally intensive, the Makefile
runs it in parallel. To change the number of processors used, edit the variable NPROCS
in the Makefile
and adapt the decomposeParDict
file in system/
accordingly (by changing numberOfSubdomains
and simpleCoeffs.n
).
Manual execution
To manually execute the commands, follow this sequence:
# Run blockMesh to generate the background mesh
$ blockMesh
# Extract surface features from the STL files
# These are used by snappyHexMesh to determine where to snap to
$ surfaceFeatureExtract
# Decompose the problem into subproblems assigned to each processor.
# The number of processors can be changed in system/decomposeParDict
$ decomposePar
# Run snappyHexMesh.
# Change the number of processes (8 here) to match your configuration and hardware.
$ mpirun -np 8 snappyHexMesh -overwrite -parallel
# Reconstruct the mesh from the processor subdomains.
# After this you can open the mesh in ParaView.
$ reconstructParMesh -constant
# Check mesh quality and look for problematic cells.
$ checkMesh
# Remove the processor folders, now unneded.
$ rm -rf processor*
Known issues
- Sometimes when using a fine background mesh the cells on the inside of the rocket aren’t removed. This is because the STL surfaces are not “waterproof”, and there are small gaps between the parts (e.g. the nosecone and the main body tube). This can be fixed by using a coarser mesh, using higher resolution STLs, or using one single STL (as opposed to combining several parts).
- If the refinement process doesn’t go far enough, try increasing
system/snappyHexMeshDict.castellatedMeshControls.maxLocalCells
(andmaxGlobalCells
), but be careful – you can easily run out of RAM if you overdo it!