OpenFOAM: Difference between revisions
(Marked this version for translation) |
(Compute Canada -> Alliance) |
||
(4 intermediate revisions by 3 users not shown) | |||
Line 14: | Line 14: | ||
* The OpenFOAM Foundation Ltd., with web sites [https://openfoam.org/ openfoam.org] and [https://cfd.direct/ cfd.direct] | * The OpenFOAM Foundation Ltd., with web sites [https://openfoam.org/ openfoam.org] and [https://cfd.direct/ cfd.direct] | ||
* OpenCFD Ltd., with web site [https://www.openfoam.com/ openfoam.com] | * OpenCFD Ltd., with web site [https://www.openfoam.com/ openfoam.com] | ||
Up to version 2.3.1, released in December 2014, the release histories appear to be the same. | Up to version 2.3.1, released in December 2014, the release histories appear to be the same. On our clusters, module names after 2.3.1 which begin with "v" are derived from the .com branch (for example, <tt>openfoam/v1706</tt>); those beginning with a digit are derived from the .org branch (for example, <tt>openfoam/4.1</tt>). | ||
<!--T:4--> | <!--T:4--> | ||
Line 61: | Line 61: | ||
<!--T:12--> | <!--T:12--> | ||
blockMesh | blockMesh | ||
setFields | setFields | ||
decomposePar | |||
srun interFoam -parallel | srun interFoam -parallel | ||
}} | }} | ||
Line 83: | Line 83: | ||
===Performance=== <!--T:14--> | ===Performance=== <!--T:14--> | ||
OpenFOAM can emit a lot of debugging information in very frequent small writes (e.g. hundreds per second). This may lead to poor performance on our | OpenFOAM can emit a lot of debugging information in very frequent small writes (e.g. hundreds per second). This may lead to poor performance on our shared filesystems. If you are in stable production and don't need the debug output, you can reduce or disable it with: | ||
{{Commands | {{Commands | ||
|mkdir -p $HOME/.OpenFOAM/$WM_PROJECT_VERSION | |mkdir -p $HOME/.OpenFOAM/$WM_PROJECT_VERSION | ||
|cp $WM_PROJECT_DIR/etc/controlDict $HOME/.OpenFOAM/$WM_PROJECT_VERSION/ | |cp $WM_PROJECT_DIR/etc/controlDict $HOME/.OpenFOAM/$WM_PROJECT_VERSION/ | ||
}} | }} | ||
There are a variety of other parameters which can be used to reduce the amount of output that OpenFOAM writes to disk as well as the frequency; these run-time parameters are documented for [https://cfd.direct/openfoam/user-guide/v6-controldict/ version 6] and [https://cfd.direct/openfoam/user-guide/v7-controldict/ version 7]. | |||
<!--T: | <!--T:19--> | ||
For example, the <code>debugSwitches</code> dictionary in <code>$HOME/.OpenFOAM/$WM_PROJECT_VERSION/controlDict</code> can be altered to change the flags from values greater than zero to zero. Another solution would be to make use of the local scratch (<tt>$SLURM_TMPDIR</tt>), a disk attached directly to the compute node, discussed [[Handling_large_collections_of_files#Local_disk|here]]. | |||
</translate> | </translate> |
Latest revision as of 14:25, 26 August 2022
The OpenFOAM (Open Field Operation and Manipulation) CFD Toolbox is a free, open source software package for computational fluid dynamics. OpenFOAM has an extensive range of features to solve anything from complex fluid flows involving chemical reactions, turbulence and heat transfer, to solid dynamics and electromagnetics.
Module files[edit]
To load the recent version, run
[name@server ~]$ module load openfoam
The OpenFOAM development community consists of:
- The OpenFOAM Foundation Ltd., with web sites openfoam.org and cfd.direct
- OpenCFD Ltd., with web site openfoam.com
Up to version 2.3.1, released in December 2014, the release histories appear to be the same. On our clusters, module names after 2.3.1 which begin with "v" are derived from the .com branch (for example, openfoam/v1706); those beginning with a digit are derived from the .org branch (for example, openfoam/4.1).
See Using modules for more on module commands.
Documentation[edit]
OpenFOAM.com documentation and CFD Direct user guide.
Usage[edit]
OpenFOAM requires substantial preparation of your environment. In order to run OpenFOAM commands (such as paraFoam
, blockMesh
, etc), you must load a module file.
Here is an example of a serial submission script for OpenFOAM 5.0:
#!/bin/bash
#SBATCH --time=00:01:00
#SBATCH --account=def-someuser
module purge
module load openfoam/5.0
blockMesh
icoFoam
Here is an example of a parallel submission script:
#!/bin/bash
#SBATCH --account=def-someuser
#SBATCH --ntasks=4 # number of MPI processes
#SBATCH --mem-per-cpu=1024M # memory; default unit is megabytes
#SBATCH --time=0-00:10 # time (DD-HH:MM)
module purge
module load openfoam/5.0
blockMesh
setFields
decomposePar
srun interFoam -parallel
Mesh preparation (blockMesh
) may be fast enough to be done at the command line (see Running jobs). The solver (icoFoam
and others) is usually the most expensive step and should always be submitted as a Slurm job except in very small test cases or tutorials.
Segfaults with OpenMPI 3.1.2[edit]
Users have reported random segfaults on Cedar when using OpenFOAM versions compiled for OpenMPI 3.1.2 in single-node jobs (shared memory communication). These issues seem not to happen with other versions of OpenMPI. If you experience such problems, first try to use an OpenMPI 2.1.1-based toolchain. For example:
[name@server ~]$ module load gcc/5.4.0
[name@server ~]$ module load openmpi/2.1.1
[name@server ~]$ module load openfoam/7
Performance[edit]
OpenFOAM can emit a lot of debugging information in very frequent small writes (e.g. hundreds per second). This may lead to poor performance on our shared filesystems. If you are in stable production and don't need the debug output, you can reduce or disable it with:
[name@server ~]$ mkdir -p $HOME/.OpenFOAM/$WM_PROJECT_VERSION
[name@server ~]$ cp $WM_PROJECT_DIR/etc/controlDict $HOME/.OpenFOAM/$WM_PROJECT_VERSION/
There are a variety of other parameters which can be used to reduce the amount of output that OpenFOAM writes to disk as well as the frequency; these run-time parameters are documented for version 6 and version 7.
For example, the debugSwitches
dictionary in $HOME/.OpenFOAM/$WM_PROJECT_VERSION/controlDict
can be altered to change the flags from values greater than zero to zero. Another solution would be to make use of the local scratch ($SLURM_TMPDIR), a disk attached directly to the compute node, discussed here.