BwUniCluster2.0/Software/OpenFoam: Difference between revisions

From bwHPC Wiki
Jump to navigation Jump to search
Line 48: Line 48:
== General information ==
== General information ==


To run any job in a parallel mode with OpenFOAM, it is necessary to decompose the geometry domain into segments, equal to the number of processors (or threads) you intend to use. That means, for example, if you have a case with a mesh which consist of 100 000 cells, to run your solver in parallel on 10 processors you will have to decompose the mesh in 10 segments, first. Then, you start the solver in ''parallel'' mode, letting ''OpenFOAM'' (through ''mpi'') to run calculations concurrently on these segments, one processor responding for one segment of the mesh, sharing the data with all other processors in between. There is, of course, a mechanism that connects properly the calculations, so you don't loose your data or generate wrong results. Decomposition and segments building process is handled by<span style="background:#edeae2;margin:10px;padding:1px;border:1px dotted #808080">decomposePar</span>utility. In " ''system/decomposeParDict'' " you may specify, how many "segments" you want your geometry domain to be divided in, and which decomposition method to use. The automatic one is " ''scotch'' ". It trims the mesh, collecting as many cells as possible per processor, trying to avoid having empty segments or segments with few cells. If you want your mesh to be divided in other way, specifying the number of segments it should be cut in x, y or z direction, for example, you can use "simple" or "hierarchical" methods. There are some other ways as well, with more documentation on the internet.
To run any job in a parallel mode with OpenFOAM, it is necessary to decompose the geometry domain into segments, equal to the number of processors (or threads) you intend to use. That means, for example, if you want to run a case on 10 processors, you will have to decompose the mesh in 10 segments, first. Then, you start the solver in ''parallel'' mode, letting ''OpenFOAM'' to run calculations concurrently on these segments, one processor responding for one segment of the mesh, sharing the data with all other processors in between. There is, of course, a mechanism that connects properly the calculations, so you don't loose your data or generate wrong results. Decomposition and segments building process is handled by<span style="background:#edeae2;margin:10px;padding:1px;border:1px dotted #808080">decomposePar</span>utility. In " ''system/decomposeParDict'' " you may specify, how many "segments" you want your geometry domain to be divided in, and which decomposition method to use. The automatic one is " ''scotch'' ". It trims the mesh, collecting as many cells as possible per processor, trying to avoid having empty segments or segments with few cells. If you want your mesh to be divided in other way, specifying the number of segments it should be cut in x, y or z direction, for example, you can use "simple" or "hierarchical" methods. There are some other ways as well, with more documentation on the internet.


----
----

Revision as of 15:22, 18 August 2015

OpenFOAM

OpenfoamLogo.png

Module:        cae/openfoam/'version'
Target System: Red-Hat-Enterprise-Linux-Server-release-6.4-Santiago 
Main Location: /opt/bwhpc/common
Priority:      mandatory
License:       GPL
Homepage:      http://www.openfoam.org/

Accessing and basic usage

The OpenFOAM® (Open Field Operation and Manipulation) CFD Toolbox is a free, open source CFD software package with an extensive range of features to solve anything from complex fluid flows involving chemical reactions, turbulence and heat transfer, to solid dynamics and electromagnetics.

In order to check what OpenFOAM versions are installed on the system, run the following command:

$ module avail cae/openfoam

Typically, several OpenFOAM versions might be available.

Any available version can be accessed by loading the appropriate module:

$ module load cae/openfoam/<version>

with <version> specifying the desired version.

To activate the OpenFOAM applications, after the module is loaded, run the following:

$ source $FOAM_INIT

or simply:

$ foamInit

Improving parallel run performance

To improve the concurrently solving process and decrease the error occurrence probability while running an OpenFOAM job in parallel (on a singlenode), some modifications have been introduced. Specifically, after the case decomposition is done, it is recommended to save the decomposed data directly on the nodes in the pre-allocated work-space and use it from there. When the calculations are over, the data is moved back to the case folder and reconstructed. It will improve the overall performance, considering that you allocated enough wall-time to decompose and rebuild your cases, as it moves theprocessor*folders to and out of the nodes local work-space. For such a procedure it is necessary to use the following commands for decomposition and reconstruction of the geometry domain:

$ decomposeParHPC
$ reconstructParHPC
$ reconstructParMeshHPC

instead of:

$ decomposPar
$ reconstructPar
$ recontructParMesh

For example, if you want to runsnappyHexMeshin parallel, you may use the following commands:

$ decomposeParMeshHPC
$ mpiexec snappyHexMesh -overwrite
$ reconstructParMeshHPC -constant

instead of:

$ decomposePar
$ mpiexec snappyHexMesh -overwrite
$ reconstructParMesh -constant

Building an OpenFOAM batch file for parallel processing

General information

To run any job in a parallel mode with OpenFOAM, it is necessary to decompose the geometry domain into segments, equal to the number of processors (or threads) you intend to use. That means, for example, if you want to run a case on 10 processors, you will have to decompose the mesh in 10 segments, first. Then, you start the solver in parallel mode, letting OpenFOAM to run calculations concurrently on these segments, one processor responding for one segment of the mesh, sharing the data with all other processors in between. There is, of course, a mechanism that connects properly the calculations, so you don't loose your data or generate wrong results. Decomposition and segments building process is handled bydecomposeParutility. In " system/decomposeParDict " you may specify, how many "segments" you want your geometry domain to be divided in, and which decomposition method to use. The automatic one is " scotch ". It trims the mesh, collecting as many cells as possible per processor, trying to avoid having empty segments or segments with few cells. If you want your mesh to be divided in other way, specifying the number of segments it should be cut in x, y or z direction, for example, you can use "simple" or "hierarchical" methods. There are some other ways as well, with more documentation on the internet.