NinjaFOAM

NinjaFOAM

This page documents the individual steps in a NinjaFOAM simulation. These steps are executed in ninjafoam::simulate_wind().

1. A temporary case directory is created and the OpenFOAM files are written in 0/, constant/, system/ located in the temporary directory. The OpenFOAM files are copied from template files located in WINDNINJA_DATA/ninjafoam.zip.

2. The DEM is converted to binary STL format and written to constant/triSurface.

3. We move into the temp directory and call surfaceTransformPoints.

   surfaceTransformPoints -translate "(0 0 <outputWindHeight>)" constant/triSurface/<demBaseName>.stl constant/triSurface/<demBaseName>_out.stl

   This creates an STL of the output surface. This is a surface shifted to the user-specified output wind height. It is written to constant/triSurface/<demBaseName>_out.stl. A log file is written to surfaceTransformPoints.log.

4. We call surfaceCheck constant/triSurface/<demBaseName>.stl. This performs a check on the generated STL and writes a file called log.json which is later used in the blockMeshDict file writing.

5. We move back out of the temp directory and write blockMeshDict. During this step, xmin, xmax, ymin, ymax, zmin, zmax, zmid are read/calculated from log.json. This is the bounding box for blockMesh. Two blocks (volumes) are created. Volume 1 is near the terrain and has a fixed vertical coordinate. The top of volume 1 (zmid) is the max terrain height + 1000 m. Volume 2 is above volume 1 and the vertical coordinate increases with height according to a calculated expansion ratio. The top of volume 2 (zmax) is the max terrain height + 3000 m. Nx1, Nx2, Ny1, Ny2, Nz1, Nz2 are also written to blockMeshDict -- these are the number of cells in the x/y/z direction in zone 1/2. See ninjafoam::readLogFile().

6. The snappyHexMeshDict files (snappyHexMeshDict_cast and snappyHexMeshDict_layer) are written. snappyHexMeshDict_cast is written first. This file generates the castellated mesh and controls snapping to the surface. There are a lot of settings to change in here. The level of refinement, e.g., level (0 0), and resolveFeatureAngle in castellatedMeshControls appears to have a substantial effect on mesh quality near the terrain and the final flow solution. Increasing the level of refinement also substantially increases the meshing time. snappyHexMeshDict_layer is written after the castellatedMesh and snap steps have been executed. This file adds the boundary layer cells. Layers are added to the minZ (the bottom of the mesh, which is defined as the lowest point in the terrain in blockMeshDict) and patch0 (the terrain) surfaces. NOTE: It is not clear why the minZ surface is present in the final mesh -- it seems that patch0 should be the bottom surface. It appears that perhaps minZ is still present in the final mesh because there are small holes in patch0 due to issues in snappyHexMesh. Note that 'snappyHexMeshDict_layeroverwrites the previoussnappyHexMeshDict_castfile (both files are written tosnappyHexMeshDict` when they are copied from their template files).

   We should look into terrainBlockMesher to replace our current meshing strategy. terrainBlockMesher generates a structured mesh based on the blockMesh utility. It is available here.

7. We move back into the temp directory and run blockMesh. A log file is written to logMesh.

8. snappyHexMesh is run twice, once to generate the castellated mesh and snap to the surface, then again to add the boundary layer cells. snappyHexMesh runs in parallel if more than one processor is available.

9. The mesh is renumbered.

10. checkMesh is run. A log file is written to log.checkMesh.

11. applyInit is run. This applies the initial conditions. A log file is written to log.

12. simpleFoam is run, in parallel if more than one processor is available.

13. The velocity field is sampled to the user-specified output height. The syntax is sample -latestTime and is controlled by sampleDict. The sampling is performed on the output surface <demBaseName>_out.stl created at the beginning of the simulation. There are several types of interpolation schemes available: cell, cellPoint, cellPointFace, etc. But only the cell scheme appears to work for our simulations. This may have to do with our meshing issues and needs to be looked into further. This generates an xyz file that we use to create our usual output formats. A log file is written to log.

14. We move back out of the temp directory and write the output files.