GitLab

- previously introduced `getOrDefault` as a dictionary _get_ method,
  now complete the transition and use it everywhere instead of
  `lookupOrDefault`. This avoids mixed usage of the two methods that
  are identical in behaviour, makes for shorter names, and promotes
  the distinction between "lookup" access (ie, return a token stream,
  locate and return an entry) and "get" access (ie, the above with
  conversion to concrete types such as scalar, label etc).

1) New skewCorrectedSnGrad for non-orthogonal and skewness corrector
2) New freeSurfacePressure and freeSurfacePressure working with
   interfaceTrackingFvMesh
3) New interfaceTrackingFvMesh

- this helps for trapping unguarded dictionary lookups.

- 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");

- make the purpose more explicit, and reduces some work for the
  compiler as well.

- when constructing dimensioned fields that are to be zero-initialized,
  it is preferrable to use a form such as

      dimensionedScalar(dims, Zero)
      dimensionedVector(dims, Zero)

  rather than

      dimensionedScalar("0", dims, 0)
      dimensionedVector("zero", dims, vector::zero)

  This reduces clutter and also avoids any suggestion that the name of
  the dimensioned quantity has any influence on the field's name.

  An even shorter version is possible. Eg,

      dimensionedScalar(dims)

  but reduces the clarity of meaning.

- NB: UniformDimensionedField is an exception to these style changes
  since it does use the name of the dimensioned type (instead of the
  regIOobject).

Improve alignment of its behaviour with std::unique_ptr

  - element_type typedef
  - release() method - identical to ptr() method
  - get() method to get the pointer without checking and without releasing it.
  - operator*() for dereferencing

Method name changes

  - renamed rawPtr() to get()
  - renamed rawRef() to ref(), removed unused const version.

Removed methods/operators

  - assignment from a raw pointer was deleted (was rarely used).
    Can be convenient, but uncontrolled and potentially unsafe.
    Do allow assignment from a literal nullptr though, since this
    can never leak (and also corresponds to the unique_ptr API).

Additional methods

  - clone() method: forwards to the clone() method of the underlying
    data object with argument forwarding.

  - reset(autoPtr&&) as an alternative to operator=(autoPtr&&)

STYLE: avoid implicit conversion from autoPtr to object type in many places

- existing implementation has the following:

     operator const T&() const { return operator*(); }

  which means that the following code works:

       autoPtr<mapPolyMesh> map = ...;
       updateMesh(*map);    // OK: explicit dereferencing
       updateMesh(map());   // OK: explicit dereferencing
       updateMesh(map);     // OK: implicit dereferencing

  for clarity it may preferable to avoid the implicit dereferencing

- prefer operator* to operator() when deferenced a return value
  so it is clearer that a pointer is involve and not a function call
  etc    Eg,   return *meshPtr_;  vs.  return meshPtr_();

Adds overset discretisation to selected physics:
- diffusion : overLaplacianDyMFoam
- incompressible steady : overSimpleFoam
- incompressible transient : overPimpleDyMFoam
- compressible transient: overRhoPimpleDyMFoam
- two-phase VOF: overInterDyMFoam

The overset method chosen is a parallel, fully implicit implementation
whereby the interpolation (from donor to acceptor) is inserted as an
adapted discretisation on the donor cells, such that the resulting matrix
can be solved using the standard linear solvers.

Above solvers come with a set of tutorials, showing how to create and set-up
simple simulations from scratch.

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.

except turbulence and lagrangian which will also be updated shortly.

For example in the nonNewtonianIcoFoam offsetCylinder tutorial the viscosity
model coefficients may be specified in the corresponding "<type>Coeffs"
sub-dictionary:

transportModel  CrossPowerLaw;

CrossPowerLawCoeffs
{
    nu0         [0 2 -1 0 0 0 0]  0.01;
    nuInf       [0 2 -1 0 0 0 0]  10;
    m           [0 0 1 0 0 0 0]   0.4;
    n           [0 0 0 0 0 0 0]   3;
}

BirdCarreauCoeffs
{
    nu0         [0 2 -1 0 0 0 0]  1e-06;
    nuInf       [0 2 -1 0 0 0 0]  1e-06;
    k           [0 0 1 0 0 0 0]   0;
    n           [0 0 0 0 0 0 0]   1;
}

which allows a quick change between models, or using the simpler

transportModel  CrossPowerLaw;

nu0         [0 2 -1 0 0 0 0]  0.01;
nuInf       [0 2 -1 0 0 0 0]  10;
m           [0 0 1 0 0 0 0]   0.4;
n           [0 0 0 0 0 0 0]   3;

if quick switching between models is not required.

To support this more convenient parameter specification the inconsistent
specification of seedSampleSet in the streamLine and wallBoundedStreamLine
functionObjects had to be corrected from

    // Seeding method.
    seedSampleSet   uniform;  //cloud; //triSurfaceMeshPointSet;

    uniformCoeffs
    {
        type        uniform;
        axis        x;  //distance;

        // Note: tracks slightly offset so as not to be on a face
        start       (-1.001 -0.05 0.0011);
        end         (-1.001 -0.05 1.0011);
        nPoints     20;
    }

to the simpler

    // Seeding method.
    seedSampleSet
    {
        type        uniform;
        axis        x;  //distance;

        // Note: tracks slightly offset so as not to be on a face
        start       (-1.001 -0.05 0.0011);
        end         (-1.001 -0.05 1.0011);
        nPoints     20;
    }

which also support the "<type>Coeffs" form

    // Seeding method.
    seedSampleSet
    {
        type        uniform;

        uniformCoeffs
        {
            axis        x;  //distance;

            // Note: tracks slightly offset so as not to be on a face
            start       (-1.001 -0.05 0.0011);
            end         (-1.001 -0.05 1.0011);
            nPoints     20;
        }
    }

Applies a displacementLaplacian on top of a solid-body motion function

e.g. the motion of two counter-rotating AMI regions could be defined:

dynamicFvMesh   dynamicMotionSolverListFvMesh;

solvers
(
    rotor1
    {
        solver solidBody;

        cellZone        rotor1;

        solidBodyMotionFunction  rotatingMotion;
        rotatingMotionCoeffs
        {
            origin        (0 0 0);
            axis          (0 0 1);
            omega         6.2832; // rad/s
        }
    }

    rotor2
    {
        solver solidBody;

        cellZone        rotor2;

        solidBodyMotionFunction  rotatingMotion;
        rotatingMotionCoeffs
        {
            origin        (0 0 0);
            axis          (0 0 1);
            omega         -6.2832; // rad/s
        }
    }
);

Any combination of motion solvers may be selected but there is no special
handling of motion interaction; the motions are applied sequentially and
potentially cumulatively.

To support this new general framework the solidBodyMotionFvMesh and
multiSolidBodyMotionFvMesh dynamicFvMeshes have been converted into the
corresponding motionSolvers solidBody and multiSolidBody and the tutorials
updated to reflect this change e.g. the motion in the mixerVesselAMI2D tutorial
is now defined thus:

dynamicFvMesh   dynamicMotionSolverFvMesh;

solver solidBody;

solidBodyCoeffs
{
    cellZone        rotor;

    solidBodyMotionFunction  rotatingMotion;
    rotatingMotionCoeffs
    {
        origin        (0 0 0);
        axis          (0 0 1);
        omega         6.2832; // rad/s
    }
}

Requires gcc version 4.7 or higher

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.

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 22f4ad32

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 4a57b9be

This is a very simple text substitution change which can be applied to
any code which compiles with the OpenFOAM-dev libraries.

e.g. (fvc::interpolate(HbyA) & mesh.Sf()) -> fvc::flux(HbyA)

This removes the need to create an intermediate face-vector field when
computing fluxes which is more efficient, reduces the peak storage and
improved cache coherency in addition to providing a simpler and cleaner
API.

Moved file path handling to regIOobject and made it type specific so
now every object can have its own rules. Examples:
- faceZones are now processor local (and don't search up anymore)
- timeStampMaster is now no longer hardcoded inside IOdictionary
  (e.g. uniformDimensionedFields support it as well)
- the distributedTriSurfaceMesh is properly processor-local; no need
  for fileModificationChecking manipulation.