Correcting header in tabulatedNTUHeatTransfer from fileName to file

Fixing humidityTemperatureCoupled problem in parallel
Adding Allrun-parallel to externalSolarLoad and windshieldCondensation tutorials

- Use on/off vs longer compressed/uncompressed.
  For consistency, replaced yes/no with on/off.

- Avoid the combination of binary/compressed,
  which is disallowed and provokes a warning anyhow

Adding intertial term switch to solarLoad chtMultiRegionFoam case

Updating fvSolution's for closed domains for chtMultiRegionFoam cases

The fundamental properties provided by the specie class hierarchy were
mole-based, i.e. provide the properties per mole whereas the fundamental
properties provided by the liquidProperties and solidProperties classes are
mass-based, i.e. per unit mass.  This inconsistency made it impossible to
instantiate the thermodynamics packages (rhoThermo, psiThermo) used by the FV
transport solvers on liquidProperties.  In order to combine VoF with film and/or
Lagrangian models it is essential that the physical propertied of the three
representations of the liquid are consistent which means that it is necessary to
instantiate the thermodynamics packages on liquidProperties.  This requires
either liquidProperties to be rewritten mole-based or the specie classes to be
rewritten mass-based.  Given that most of OpenFOAM solvers operate
mass-based (solve for mass-fractions and provide mass-fractions to sub-models it
is more consistent and efficient if the low-level thermodynamics is also
mass-based.

This commit includes all of the changes necessary for all of the thermodynamics
in OpenFOAM to operate mass-based and supports the instantiation of
thermodynamics packages on liquidProperties.

Note that most users, developers and contributors to OpenFOAM will not notice
any difference in the operation of the code except that the confusing

    nMoles     1;

entries in the thermophysicalProperties files are no longer needed or used and
have been removed in this commet.  The only substantial change to the internals
is that species thermodynamics are now "mixed" with mass rather than mole
fractions.  This is more convenient except for defining reaction equilibrium
thermodynamics for which the molar rather than mass composition is usually know.
The consequence of this can be seen in the adiabaticFlameT, equilibriumCO and
equilibriumFlameT utilities in which the species thermodynamics are
pre-multiplied by their molecular mass to effectively convert them to mole-basis
to simplify the definition of the reaction equilibrium thermodynamics, e.g. in
equilibriumCO

    // Reactants (mole-based)
    thermo FUEL(thermoData.subDict(fuelName)); FUEL *= FUEL.W();

    // Oxidant (mole-based)
    thermo O2(thermoData.subDict("O2")); O2 *= O2.W();
    thermo N2(thermoData.subDict("N2")); N2 *= N2.W();

    // Intermediates (mole-based)
    thermo H2(thermoData.subDict("H2")); H2 *= H2.W();

    // Products (mole-based)
    thermo CO2(thermoData.subDict("CO2")); CO2 *= CO2.W();
    thermo H2O(thermoData.subDict("H2O")); H2O *= H2O.W();
    thermo CO(thermoData.subDict("CO")); CO *= CO.W();

    // Product dissociation reactions

    thermo CO2BreakUp
    (
        CO2 == CO + 0.5*O2
    );

    thermo H2OBreakUp
    (
        H2O == H2 + 0.5*O2
    );

Please report any problems with this substantial but necessary rewrite of the
thermodynamic at https://bugs.openfoam.org

Henry G. Weller
CFD Direct Ltd.

Bounding thermo.rho in rhoPorousSimpleFoam.
Changing initial time step in externalSolarLoad tutorial.
Commenting out momemtun source term in steamInjection which causes problems

- A few without a 'cd' at the start.
  Use $(getApplication) directly in more places (for clarity).

- A few without a 'cd' at the start.
  Several remove files that are already covered by the cleanCase function.

- In the corner case with few faces or points, the normal List I/O
  results in a compact list representation.

  This is less than desirable for external programs with simple
  line-based parsers.

- Write exactly the following

*Faces*
// Patch: <word-Region> <word-Patch>
<int-nFaces>
(
<int-faceSize>(<int> .. <int>)
...
)

*Points*
// Patch: <word-Region> <word-Patch>
<int-nPoints>
(
(<float-x> <float-y> <float-z>)
...
)

STYLE: only use serial form of createExternalCoupledPatchGeometry in tutorial

- less confusing for the user, who wonders why it is being done twice.

- This provides a mechanism for the external code to detect when
  OpenFOAM is done.

- Adjust tutorial to use the mechanism. Also test in parallel.

using a run-time selectable preconditioner

References:
    Van der Vorst, H. A. (1992).
    Bi-CGSTAB: A fast and smoothly converging variant of Bi-CG
    for the solution of nonsymmetric linear systems.
    SIAM Journal on scientific and Statistical Computing, 13(2), 631-644.

    Barrett, R., Berry, M. W., Chan, T. F., Demmel, J., Donato, J.,
    Dongarra, J., Eijkhout, V., Pozo, R., Romine, C. & Van der Vorst, H.
    (1994).
    Templates for the solution of linear systems:
    building blocks for iterative methods
    (Vol. 43). Siam.

See also: https://en.wikipedia.org/wiki/Biconjugate_gradient_stabilized_method

Tests have shown that PBiCGStab with the DILU preconditioner is more
robust, reliable and shows faster convergence (~2x) than PBiCG with
DILU, in particular in parallel where PBiCG occasionally diverges.

This remarkable improvement over PBiCG prompted the update of all
tutorial cases currently using PBiCG to use PBiCGStab instead.  If any
issues arise with this update please report on Mantis: http://bugs.openfoam.org

- makes it easier to ensure the correct behaviour, consistently

changeDictionary: Simplified by removing the need for the superfluous dictionaryReplacement sub-dictionary

Added the option '-subDict' to specify a sub-dictionary if multiple
replacement sets are present in the same file.  This also provides
backward compatibility by setting '-subDict dictionaryReplacement'

values; formatted Switch entries consistently across all cases

In most boundary conditions, fvOptions etc. required and optional fields
to be looked-up from the objectRegistry are selected by setting the
keyword corresponding to the standard field name in the BC etc. to the
appropriate name in the objectRegistry.  Usually a default is provided
with sets the field name to the keyword name, e.g. in the
totalPressureFvPatchScalarField the velocity is selected by setting the
keyword 'U' to the appropriate name which defaults to 'U':

        Property     | Description             | Required    | Default value
        U            | velocity field name     | no          | U
        phi          | flux field name         | no          | phi
        .
        .
        .

However, in some BCs and functionObjects and many fvOptions another
convention is used in which the field name keyword is appended by 'Name'
e.g.

        Property     | Description             | Required    | Default value
        pName        | pressure field name     | no          | p
        UName        | velocity field name     | no          | U

This difference in convention is unnecessary and confusing, hinders code
and dictionary reuse and complicates code maintenance.  In this commit
the appended 'Name' is removed from the field selection keywords
standardizing OpenFOAM on the first convention above.

  - Avoids the need for the 'OutputFilterFunctionObject' wrapper
  - Time-control for execution and writing is now provided by the
    'timeControlFunctionObject' which instantiates the processing
    'functionObject' and controls its operation.
  - Alternative time-control functionObjects can now be written and
    selected at run-time without the need to compile wrapped version of
    EVERY existing functionObject which would have been required in the
    old structure.
  - The separation of 'execute' and 'write' functions is now formalized in the
    'functionObject' base-class and all derived classes implement the
    two functions.
  - Unnecessary implementations of functions with appropriate defaults
    in the 'functionObject' base-class have been removed reducing
    clutter and simplifying implementation of new functionObjects.
  - The 'coded' 'functionObject' has also been updated, simplified and tested.
  - Further simplification is now possible by creating some general
    intermediate classes derived from 'functionObject'.