OpenFOAM is the most widely used open-source CFD toolbox, and the fastest way to learn it is to run a case that already works. This walkthrough takes the bundled pitzDaily case — a classic backward-facing step — from a copied directory to viewable results, covering the four steps every OpenFOAM run shares: mesh, check, solve, review.

You do not need to understand the solver internals yet. The goal here is to build the muscle memory of the workflow so that, when you set up your own geometry, the mechanics are already familiar.

Prerequisites

You need a working OpenFOAM installation and its environment sourced into your shell. On a Linux install the environment script is typically loaded like this (the exact path depends on your version):

source /opt/openfoam12/etc/bashrc

If blockMesh and simpleFoam resolve on the command line afterwards, you are ready. See the official download and installation guide if not.

Step 1 — Copy a tutorial case

Never edit tutorials in place — copy them into your own run directory so the originals stay clean:

mkdir -p $HOME/run && cd $HOME/run
cp -r $FOAM_TUTORIALS/incompressible/simpleFoam/pitzDaily .
cd pitzDaily
ls

You will see the three directories every OpenFOAM case has: 0 (initial and boundary conditions), constant (mesh and physical properties), and system (solver and discretization settings).

Step 2 — Generate the mesh with blockMesh

The mesh is defined parametrically in system/blockMeshDict. The blockMesh utility reads that dictionary and writes the mesh into constant/polyMesh:

blockMesh

A successful run ends with End and no error. blockMesh is the right tool for simple, block-structured geometries like this one; complex real-world geometry is where automated meshing earns its keep (more on that below).

Step 3 — Check the mesh with checkMesh

Always validate the mesh before spending solver time on it. checkMesh reports cell counts, non-orthogonality, and skewness:

checkMesh

Look for the final line: Mesh OK. Warnings about high non-orthogonality or skewness are the most common cause of a solver that diverges or stalls — catching them here saves hours.

Step 4 — Run the solver with simpleFoam

pitzDaily is a steady-state, incompressible case, so it uses the simpleFoam solver (named for the SIMPLE algorithm). Run it and pipe the log to a file so you can monitor convergence:

simpleFoam | tee log.simpleFoam

The residuals printed each iteration should trend downward. When they fall below the convergence criteria in system/fvSolution, the run stops on its own and writes time directories (100, 200, …) containing the solution fields.

Step 5 — Review the results

OpenFOAM ships with a ParaView reader. The quickest way to open the case is:

paraFoam

In ParaView, colour the domain by velocity magnitude (U) to see the recirculation zone behind the step — the feature this case is famous for. For headless or scripted post-processing, use the postProcess utility instead, for example to sample fields or compute forces without a GUI.

Where to go next

Once this loop feels routine, the natural next step is your own geometry — and that is where the workflow gets harder. blockMesh does not scale to complex CAD; you move to snappyHexMesh and spend real time tuning refinement regions and layer settings per part.

That meshing step is the usual bottleneck in moving from tutorials to production. Khorium’s MeshGen targets exactly this: it produces solver-ready meshes from real geometry without hand-placed refinement zones, and SimOps drives the full mesh-check-solve-review loop on cloud compute. The four steps stay the same — automation just removes the manual tuning between them.