Commit Graph

13 Commits

Author SHA1 Message Date
b9123328fb typeIOobject: Template typed form of IOobject for type-checked object file and header reading
used to check the existence of and open an object file, read and check the
header without constructing the object.

'typeIOobject' operates in an equivalent and consistent manner to 'regIOobject'
but the type information is provided by the template argument rather than via
virtual functions for which the derived object would need to be constructed,
which is the case for 'regIOobject'.

'typeIOobject' replaces the previous separate functions 'typeHeaderOk' and
'typeFilePath' with a single consistent interface.
2021-08-12 10:12:03 +01:00
cc92330253 IOobject, regIOobject: rationalised handling of paths for global and local objects
now all path functions in 'IOobject' are either templated on the type or require a
'globalFile' argument to specify if the type is case global e.g. 'IOdictionary' or
decomposed in parallel, e.g. almost everything else.

The 'global()' and 'globalFile()' virtual functions are now in 'regIOobject'
abstract base-class and overridden as required by derived classes.  The path
functions using 'global()' and 'globalFile()' to differentiate between global
and processor local objects are now also in 'regIOobject' rather than 'IOobject'
to ensure the path returned is absolutely consistent with the type.

Unfortunately there is still potential for unexpected IO behaviour inconsistent
with the global/local nature of the type due to the 'fileOperation' classes
searching the processor directory for case global objects before searching the
case directory.  This approach appears to be a work-around for incomplete
integration with and rationalisation of 'IOobject' but with the changes above it
is no longer necessary.  Unfortunately this "up" searching is baked-in at a low
level and mixed-up with various complex ways to pick the processor directory
name out of the object path and will take some unravelling but this work will
undertaken as time allows.
2021-08-09 21:23:12 +01:00
66c62e9296 searchableSurface: Renamed geometry directory triSurface -> geometry
Originally the only supported geometry specification were triangulated surfaces,
hence the name of the directory: constant/triSurface, however now that other
surface specifications are supported and provided it is much more logical that
the directory is named accordingly: constant/geometry.  All tutorial and
template cases have been updated.

Note that backward compatibility is provided such that if the constant/geometry
directory does not exist but constant/triSurface does then the geometry files
are read from there.
2021-02-04 13:51:48 +00:00
bf54ab67e1 Updated OpenFOAM Foundation web-link in headers 2018-07-06 21:42:54 +01:00
88a218ce84 treeBoundBox: Removed unecessary randomisation
Tree bound boxes are expanded asymmetrically to reduce the liklihood of
octree faces aliging with mesh faces and edges. The asymmetry is now
generated using hard-coded irrational numbers, rather than using a
random generator.

The asymmetry was effectively already hard coded. The random numbers are
only pseudo random, so the same numbers were being applied to the bound
boxes every time. This change simply removes the overhead of creating
the generator, and also gets rid of some duplicated code.
2018-06-11 11:01:11 +01:00
87e32ab499 Code style: Updated line comments to start with a space
//This is a comment   ->   // This is a comment
2018-05-01 11:57:50 +01:00
fc2b2d0c05 OpenFOAM: Rationalized the naming of scalar limits
In early versions of OpenFOAM the scalar limits were simple macro replacements and the
names were capitalized to indicate this.  The scalar limits are now static
constants which is a huge improvement on the use of macros and for consistency
the names have been changed to camel-case to indicate this and improve
readability of the code:

    GREAT -> great
    ROOTGREAT -> rootGreat
    VGREAT -> vGreat
    ROOTVGREAT -> rootVGreat
    SMALL -> small
    ROOTSMALL -> rootSmall
    VSMALL -> vSmall
    ROOTVSMALL -> rootVSmall

The original capitalized are still currently supported but their use is
deprecated.
2018-01-25 09:46:37 +00:00
7c301dbff4 Parallel IO: New collated file format
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.
2017-07-07 11:39:56 +01:00
da6b1bf361 Surface utilities: standardised argument naming and ordering
for input and output surface files
2017-05-12 14:43:10 +01:00
a8bf4be58a Standardized cell, patch, face and processor loop index names 2016-04-25 12:00:53 +01:00
94c05a1e6c Update code to use the simpler C++11 template syntax removing spaces between closing ">"s 2016-01-10 22:41:16 +00:00
10aea96ae5 applications: Update ...ErrorIn -> ...ErrorInFunction
Avoids the clutter and maintenance effort associated with providing the
function signature string.
2015-11-10 17:53:31 +00:00
446e5777f0 Add the OpenFOAM source tree 2014-12-10 22:40:10 +00:00