- improves interface and data consistency.
Older signatures are still active (via the Foam_IOstream_extras
define).
- refine internals for IOstreamOption streamFormat, versionNumber
ENH: improve data alignment for IOstream and IOobject
- fit sizeof label/scalar into unsigned char
STYLE: remove dead code
- easier support for non-mandatory functions.
In some boundary conditions it can be desirable to support
additional functions, but not necessarily require them. Make this
easier to support with a Function1, PatchFunction1 NewIfPresent()
selector.
- support for compatibility lookups
- harmonize branching logic and error handling between Function1 and
PatchFunction1.
ENH: refactor a base class for Function1, PatchFunction1
- includes base characteristics, patch or scalar information
ENH: additional creation macros
- makeConcreteFunction1, makeConcretePatchFunction1Type for adding a
non-templated function into the correct templated selection table.
makeScalarPatchFunction1 for similarity with makeScalarFunction1
- slipped in with changes to csvTableReader (commit 59ed3ba18d) so
only affects the 2006 version.
- adjust constructor to expect "componentColumns", but also accept
"valueColumns" as 1912 and earlier-compatibility. This not only
fixes the reported bug, but also ensure proper compatibility with
older files.
ENH: use "refColumn" instead of "timeColumn" for csvTableReader
- consistent with the CSV Function1.
Support 'timeColumn' as 1912 and earlier-compatibility.
TUT: remove unused table-reader entry
Style changes:
- use std algorithm for some stringOps internals
- pass SubStrings iterators by const reference
ENH: special nullptr handling for ISstream getLine
- pass through to istream::ignore to support read and discard
- avoid stealing autoPtr in interpolationTable copy operations
- improve local memory requirements of readers
- make OpenFOAM table reader default constructible
- more code alignment between csvTableReader and Function1::CSV
(fix#1498 for csvTableReader as well)
- use the dictionary 'get' methods instead of readScalar for
additional checking
Unchecked: readScalar(dict.lookup("key"));
Checked: dict.get<scalar>("key");
- In templated classes that also inherit from a dictionary, an additional
'template' keyword will be required. Eg,
this->coeffsDict().template get<scalar>("key");
For this common use case, the predefined getXXX shortcuts may be
useful. Eg,
this->coeffsDict().getScalar("key");
Original commit message:
------------------------
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.
e.g.
ramp
{
type quadratic;
start 200;
duration 1.6;
}
but the old format is supported for backward compatibility:
ramp linear;
rampCoeffs
{
start 200;
duration 1.6;
}
e.g. in tutorials/heatTransfer/buoyantSimpleFoam/externalCoupledCavity/0/T
hot
{
type externalCoupledTemperature;
commsDir "${FOAM_CASE}/comms";
file "data";
initByExternal yes;
log true;
value uniform 307.75; // 34.6 degC
}
Previously both 'file' and 'fileName' were used inconsistently in different
classes and given that there is no confusion or ambiguity introduced by using
the simpler 'file' rather than 'fileName' this change simplifies the use and
maintenance of OpenFOAM.
- Include newline in beginBlock/endBlock, since this corresponds to
the standard usage. The beginBlock now takes keyType instead of word.
- Provide Ostream::writeEntry method to reduce clutter and simplify
writing of entries.
Before
======
os << indent << "name" << nl
<< indent << token::BEGIN_BLOCK << incrIndent << nl;
os.writeKeyword("key1") << val1 << token::END_STATEMENT << nl;
os.writeKeyword("key2") << val2 << token::END_STATEMENT << nl;
os << decrIndent << indent << token::END_BLOCK << nl;
After
=====
os.beginBlock("name");
os.writeEntry("key1", val1);
os.writeEntry("key2", val2);
os.endBlock();
- For completeness, support inline use of various Ostream methods.
For example,
os << beginBlock;
os.writeEntry("key1", val1);
os.writeEntry("key2", val2);
os << endBlock;
- For those who wish to write in long form, can also use endEntry inline:
os.beginBlock("name");
os.writeKeyword("key1") << val2 << endEntry;
os.writeKeyword("key2") << val2 << endEntry;
os.endBlock();
The endEntry encapsulates a semi-colon, newline combination.
Function1 is an abstract base-class of run-time selectable unary
functions which may be composed of other Function1's allowing the user
to specify complex functions of a single scalar variable, e.g. time.
The implementations need not be a simple or continuous functions;
interpolated tables and polynomials are also supported. In fact form of
mapping between a single scalar input and a single primitive type output
is supportable.
The primary application of Function1 is in time-varying boundary
conditions, it also used for other functions of time, e.g. injected mass
is spray simulations but is not limited to functions of time.
