From Core Commands to Cloud Compute: Behind the Scenes of the OpenFOAM Workshop Presentation in Guimarães
The 21th OpenFOAM Workshop in Guimarães, Portugal was a fantastic gathering of open-source CFD minds. For my session, I wanted to step away from the abstract theory and focus on something highly practical: OpenFOAM Automation.
Whether you are an absolute beginner or a seasoned simulation engineer, the message from the presentation was clear: stop hand-editing dictionaries and let bash and Python scripting drive your simulations faster.
Skip to PDF contentHere is a look at the technical toolkit covered during the presentation and how it lays the groundwork for high-throughput engineering.
The Evolution of an OpenFOAM Script
As discussed during the session, a bash script is nothing more than a plain text file containing the exact commands you would otherwise manually type into your terminal. By adding a #!/bin/bash shebang line and executing chmod +x, you turn a list of instructions into a reusable program.
The presentation highlighted a safe, production-grade scripting template using a few standard parameters:
#!/bin/bash
set -euo pipefail # Safe mode: stop immediately on any error
DIR=$(cd "$(dirname "$0")" && pwd)Using set -euo pipefail is critical for unattended batch workflows. If your geometry fails to mesh or a boundary condition file contains a syntax error, the script stops immediately rather than letting broken simulations pile up on your disk.
1. Meshing Automation via snappyHexMeshConfig
Hand-crafting blockMeshDict or snappyHexMeshDict files for every geometry iteration is a massive bottleneck. The presentation highlighted snappyHexMeshConfig, an openfoam.org native utility that scans your geometry directory, identifies your STL/OBJ surfaces, and generates all necessary meshing dictionaries automatically.
# Generating the blockMesh, surfaceFeatures, and snappyHexMesh dictionaries automatically
snappyHexMeshConfig \
-bounds ((-0.25 -0.25 -0.15) (0.25 0.25 0.15)) \
-nCells (100 100 100) \
-cellzones (rotor) \
-surfaceLevels ((impeller 4) (casing 2)) \
-layers ((impeller 6) (casing 4))By wrapping parameters like -nCells or -surfaceLevels as bash variables, you instantly create a one-line parametric mesh generator capable of sweeping varying mesh densities across a batch of geometry variations.
2. Parametric Studies via foamDictionary
If you want to sweep physical parameters—such as changing inlet velocities, turbulence settings, or rotating zones—foamDictionary is your core building block. It allows you to modify any keyword entry at any nesting depth straight from the command line, without ever opening a text editor.
# Update case entries automatically inside a bash loop
foamDictionary system/controlDict -entry endTime -set 3000
foamDictionary system/controlDict -set "startTime=0, endTime=2000, writeInterval=100"3. Smart Scripting with Inline Code (#calc)
Pairing foamDictionary with OpenFOAM’s native #calc entry creates a highly dynamic environment. Instead of calculating derived parameters (like converting RPM to angular velocity $\omega$ or computing kinematic pressure from an absolute datasheet value) in an external spreadsheet, you embed the formula right into the file.
rotor
{
cellZone rotor;
rpm 750; // Set via foamDictionary
omega #calc "$rpm * 2.0 * 3.14159265 / 60.0";
}Because #calc evaluates at runtime, updating the rpm value via a bash script automatically triggers a recalculation of omega when the solver opens the case dictionary.
From Local Sequences to Massive Cloud Tiers
The true climax of the automation journey is moving from local execution to high-performance parallel loops. If you run a multi-parameter loop locally, your workstation solves each design point sequentially. If a matrix contains 10 impellers across 4 distinct RPM tiers, that means waiting for 40 consecutive runs.
By utilizing our open-source command-line tool, cloudHPCexec, you can swap out a single row in your loop to distribute the entire parameter workspace simultaneously:
# BEFORE: Local sequential processing
(cd "$runDir" && simpleFoam > log.simpleFoam 2>&1)
# AFTER: Cloud batch submission (non-blocking)
cloudHPCexec -batch 8 highcore openFoam-of12 "$runDir"The -batch flag uploads, packs, and submits the simulation to cloudHPC.cloud and returns control to your loop immediately. Within seconds, all 40 configurations are launched concurrently on independent, dedicated compute nodes.
Post-Processing and Data Harvesting
A script shouldn’t stop when the solver reaches its endTime. By integrating function objects like patchAverage or patchFlowRate into your template controlDict, OpenFOAM outputs clean time-series tables directly to the postProcessing/ tree.
Once your cloud simulations complete, a simple one-liner bash command can skim the final converged rows across your directories and compile an instant spreadsheet table:
echo "geom, rpm, p_in, p_out" > results.csv
for dir in waterPump_impeller*_*rpm; do
p_in=$(grep -v '#' "$dir/postProcessing/patchAverage(patch=inlet)/0/surfaceFieldValue.dat" | tail -1 | awk '{print $2}')
p_out=$(grep -v '#' "$dir/postProcessing/patchAverage(patch=outlet)/0/surfaceFieldValue.dat" | tail -1 | awk '{print $2}')
echo "$dir, $p_in, $p_out" >> results.csv
doneThe Next Frontier: Where Do AI Agents Fit In?
During the presentation Q&A, an excellent question came from the floor: Can AI agents eventually replace this bash scripting layer? Can an LLM autonomously debug an OpenFOAM simulation or configure dictionaries?
It’s a critical discussion. There is a wide gap between generating an isolated boilerplate text block and deployed AI agents that can trace back an “out-of-bounds” matrix error or dynamically patch physical boundary attributes mid-run.
I shared a detailed breakdown of where AI agents hold massive potential—and exactly where they hit a hard wall when facing strict structural physics. Take 5 minutes out of your day to watch my exact video reply.
The full script library and resources showcased in this deck are available on our GitHub page. Let’s continue the discussion below: are you still hand-crafting your dictionaries, or is your workflow fully automated?
CloudHPC is a HPC provider to run engineering simulations on the cloud. CloudHPC provides from 1 to 224 vCPUs for each process in several configuration of HPC infrastructure - both multi-thread and multi-core. Current software ranges includes several CAE, CFD, FEA, FEM software among which OpenFOAM, FDS, Blender and several others.
New users benefit of a FREE trial of 300 vCPU/Hours to be used on the platform in order to test the platform, all each features and verify if it is suitable for their needs
