Commit Graph

14 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
cf552e6343 utilities: Rationalised and standardised the handling of the -dict option 2021-03-05 13:42:46 +00:00
bf54ab67e1 Updated OpenFOAM Foundation web-link in headers 2018-07-06 21:42:54 +01:00
786318cabd utilities: Centralized annotated utility dictionaries to etc/caseDicts/annotated 2018-06-11 17:20:08 +01: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
65402d6831 setFields: Added '-dict' option
Resolves bug-report http://bugs.openfoam.org/view.php?id=2366
2016-12-03 11:45:36 +00:00
fe43b80536 GeometricField: Renamed internalField() -> primitiveField() and dimensionedInternalField() -> internalField()
These new names are more consistent and logical because:

primitiveField():
primitiveFieldRef():
    Provides low-level access to the Field<Type> (primitive field)
    without dimension or mesh-consistency checking.  This should only be
    used in the low-level functions where dimensional consistency is
    ensured by careful programming and computational efficiency is
    paramount.

internalField():
internalFieldRef():
    Provides access to the DimensionedField<Type, GeoMesh> of values on
    the internal mesh-type for which the GeometricField is defined and
    supports dimension and checking and mesh-consistency checking.
2016-04-30 21:40:09 +01:00
e1e996746b GeometricField::internalField() -> GeometricField::internalFieldRef()
Non-const access to the internal field now obtained from a specifically
named access function consistent with the new names for non-canst access
to the boundary field boundaryFieldRef() and dimensioned internal field
dimensionedInternalFieldRef().

See also commit a4e2afa4b3
2016-04-30 14:25:21 +01:00
75ea76187b GeometricField::GeometricBoundaryField -> GeometricField::Boundary
When the GeometricBoundaryField template class was originally written it
was a separate class in the Foam namespace rather than a sub-class of
GeometricField as it is now.  Without loss of clarity and simplifying
code which access the boundary field of GeometricFields it is better
that GeometricBoundaryField be renamed Boundary for consistency with the
new naming convention for the type of the dimensioned internal field:
Internal, see commit a25a449c9e

This is a very simple text substitution change which can be applied to
any code which compiles with the OpenFOAM-dev libraries.
2016-04-28 07:22:02 +01:00
a8bf4be58a Standardized cell, patch, face and processor loop index names 2016-04-25 12:00:53 +01:00
6a27f7af46 boundaryField() -> boundaryFieldRef() 2016-04-24 22:07:37 +01:00
ac71f86574 UList: Rationalize assignment (shallow-copy vs deep-copy)
//- Disallow default shallow-copy assignment
    //
    //  Assignment of UList<T> may need to be either shallow (copy pointer)
    //  or deep (copy elements) depending on context or the particular type
    //  of list derived from UList and it is confusing and prone to error
    //  for the default assignment to be either.  The solution is to
    //  disallow default assignment and provide separate 'shallowCopy' and
    //  'deepCopy' member functions.
    void operator=(const UList<T>&) = delete;

    //- Copy the pointer held by the given UList.
    inline void shallowCopy(const UList<T>&);

    //- Copy elements of the given UList.
    void deepCopy(const UList<T>&);
2016-04-03 10:26:05 +01: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