When an OpenFOAM simulation runs in parallel, the data for decomposed fields and
mesh(es) has historically been stored in multiple files within separate
directories for each processor. Processor directories are named 'processorN',
where N is the processor number.
This commit introduces an alternative "collated" file format where the data for
each decomposed field (and mesh) is collated into a single file, which is
written and read on the master processor. The files are stored in a single
directory named 'processors'.
The new format produces significantly fewer files - one per field, instead of N
per field. For large parallel cases, this avoids the restriction on the number
of open files imposed by the operating system limits.
The file writing can be threaded allowing the simulation to continue running
while the data is being written to file. NFS (Network File System) is not
needed when using the the collated format and additionally, there is an option
to run without NFS with the original uncollated approach, known as
"masterUncollated".
The controls for the file handling are in the OptimisationSwitches of
etc/controlDict:
OptimisationSwitches
{
...
//- Parallel IO file handler
// uncollated (default), collated or masterUncollated
fileHandler uncollated;
//- collated: thread buffer size for queued file writes.
// If set to 0 or not sufficient for the file size threading is not used.
// Default: 2e9
maxThreadFileBufferSize 2e9;
//- masterUncollated: non-blocking buffer size.
// If the file exceeds this buffer size scheduled transfer is used.
// Default: 2e9
maxMasterFileBufferSize 2e9;
}
When using the collated file handling, memory is allocated for the data in the
thread. maxThreadFileBufferSize sets the maximum size of memory in bytes that
is allocated. If the data exceeds this size, the write does not use threading.
When using the masterUncollated file handling, non-blocking MPI communication
requires a sufficiently large memory buffer on the master node.
maxMasterFileBufferSize sets the maximum size in bytes of the buffer. If the
data exceeds this size, the system uses scheduled communication.
The installation defaults for the fileHandler choice, maxThreadFileBufferSize
and maxMasterFileBufferSize (set in etc/controlDict) can be over-ridden within
the case controlDict file, like other parameters. Additionally the fileHandler
can be set by:
- the "-fileHandler" command line argument;
- a FOAM_FILEHANDLER environment variable.
A foamFormatConvert utility allows users to convert files between the collated
and uncollated formats, e.g.
mpirun -np 2 foamFormatConvert -parallel -fileHandler uncollated
An example case demonstrating the file handling methods is provided in:
$FOAM_TUTORIALS/IO/fileHandling
The work was undertaken by Mattijs Janssens, in collaboration with Henry Weller.
unless the blockMeshDict is in the polyMesh directory or the "-noClean" option
is specified.
This avoids problems running snappyHexMesh without first clearing files from
polyMesh which interfere with the operation of snappyHexMesh.
For example, to mesh a sphere with a single block the geometry is defined in the
blockMeshDict as a searchableSurface:
geometry
{
sphere
{
type searchableSphere;
centre (0 0 0);
radius 1;
}
}
The vertices, block topology and curved edges are defined in the usual
way, for example
v 0.5773502;
mv -0.5773502;
a 0.7071067;
ma -0.7071067;
vertices
(
($mv $mv $mv)
( $v $mv $mv)
( $v $v $mv)
($mv $v $mv)
($mv $mv $v)
( $v $mv $v)
( $v $v $v)
($mv $v $v)
);
blocks
(
hex (0 1 2 3 4 5 6 7) (10 10 10) simpleGrading (1 1 1)
);
edges
(
arc 0 1 (0 $ma $ma)
arc 2 3 (0 $a $ma)
arc 6 7 (0 $a $a)
arc 4 5 (0 $ma $a)
arc 0 3 ($ma 0 $ma)
arc 1 2 ($a 0 $ma)
arc 5 6 ($a 0 $a)
arc 4 7 ($ma 0 $a)
arc 0 4 ($ma $ma 0)
arc 1 5 ($a $ma 0)
arc 2 6 ($a $a 0)
arc 3 7 ($ma $a 0)
);
which will produce a mesh in which the block edges conform to the sphere
but the faces of the block lie somewhere between the original cube and
the spherical surface which is a consequence of the edge-based
transfinite interpolation.
Now the projection of the block faces to the geometry specified above
can also be specified:
faces
(
project (0 4 7 3) sphere
project (2 6 5 1) sphere
project (1 5 4 0) sphere
project (3 7 6 2) sphere
project (0 3 2 1) sphere
project (4 5 6 7) sphere
);
which produces a mesh that actually conforms to the sphere.
See OpenFOAM-dev/tutorials/mesh/blockMesh/sphere
This functionality is experimental and will undergo further development
and generalization in the future to support more complex surfaces,
feature edge specification and extraction etc. Please get involved if
you would like to see blockMesh become a more flexible block-structured
mesher.
Henry G. Weller, CFD Direct.
blockMesh -help
Usage: blockMesh [OPTIONS]
options:
-blockTopology write block edges and centres as .obj files
-case <dir> specify alternate case directory, default is the cwd
-dict <file> specify alternative dictionary for the blockMesh description
-noFunctionObjects
do not execute functionObjects
-region <name> specify alternative mesh region
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
Block description
For a given block, the correspondence between the ordering of
vertex labels and face labels is shown below.
For vertex numbering in the sequence 0 to 7 (block, centre):
faces 0 (f0) and 1 are left and right, respectively;
faces 2 and 3 are bottom and top;
and faces 4 and 5 are front the back:
4 ---- 5
f3 |\ |\ f5
| | 7 ---- 6 \
| 0 |--- 1 | \
| \| \| f4
f2 3 ---- 2
f0 ----- f1
Using: OpenFOAM-dev (see www.OpenFOAM.org)
Build: dev-9d3f407fc741
For multi-region cases the default location of blockMeshDict is now system/<region name>
If the blockMeshDict is not found in system then the constant directory
is also checked providing backward-compatibility
