ENH: Several modifycations to avoid erroneuos rays to be shot
from wrong faces.

ENH: Updating tutorials and avoiding registration of the
coarse singleCellFvMesh

Adding solarLoad tutorial case simpleCarSolarPanel

ENH: Changes needed for the merge

Adding reflecting fluxes to Solar load radiation model.
Adding functionality to the boundary radiation models and new
place holder for basic wall types such as transparent, opaqueDiffusive,
opaqueReflective,etc.
Changing radiation wall models to run time selectable.
Adding multi-band capabilities to VF model and improving the set up
for using solar loads in VF and fvDOM radiation models.

- now replaced 'if ! isTest' with 'if notTest' for most cases.

- although this has been supported for many years, the tutorials
  continued to use "convertToMeters" entry, which is specific to blockMesh.
  The "scale" is more consistent with other dictionaries.

ENH:
- ignore "scale 0;" (treat as no scaling) for blockMeshDict,
  consistent with use elsewhere.

    #includeEtc "caseDicts/setConstraintTypes"
 vs.
    #include "${WM_PROJECT_DIR}/etc/caseDicts/setConstraintTypes"

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.

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.

Patch contributed by Bruno Santos
Resolves patch request https://bugs.openfoam.org/view.php?id=2411

- 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.

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

Resolves bug-report http://bugs.openfoam.org/view.php?id=2182

Patch contributed by Bruno Santos
Resolves bug-report http://bugs.openfoam.org/view.php?id=2173

- makes it easier to ensure the correct behaviour, consistently

values; formatted Switch entries consistently across all cases

To re-use existing 'sampleDict' files simply add the following entries:

    type sets;
    libs ("libsampling.so");

and run

    postProcess -func sampleDict

It is probably better to also rename 'sampleDict' -> 'sample' and then run

    postProcess -func sampleDict

ENH: Changing boundaryRadiationProperties to read an scalar when a lookup mode is used for boudanry radiation properties.
Tutorials updated accordingly

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.

Revert "Change boundaryRadiationProperties and boundaryRadiationPropertiesPatch to mesh object and changing tutorials accordingly"

This reverts commit 662f9242.

Note: functionality moved to feature-boundaryRadiationProperties branch

See http://www.openfoam.org/mantisbt/view.php?id=2076
  - .org is the file extension for emacs org-mode as well
  - .orig is more to the point (.org isn't always recognized as "original")
  - .original is too long, although more consistent with the convention
    of source code file naming

Update script contributed by Bruno Santos

Change boundaryRadiationProperties and boundaryRadiationPropertiesPatch to mesh object and changing tutorials accordingly

The boundary conditions of HbyA are now constrained by the new "constrainHbyA"
function which applies the velocity boundary values for patches for which the
velocity cannot be modified by assignment and pressure extrapolation is
not specified via the new
"fixedFluxExtrapolatedPressureFvPatchScalarField".

The new function "constrainPressure" sets the pressure gradient
appropriately for "fixedFluxPressureFvPatchScalarField" and
"fixedFluxExtrapolatedPressureFvPatchScalarField" boundary conditions to
ensure the evaluated flux corresponds to the known velocity values at
the boundary.

The "fixedFluxPressureFvPatchScalarField" boundary condition operates
exactly as before, ensuring the correct flux at fixed-flux boundaries by
compensating for the body forces (gravity in particular) with the
pressure gradient.

The new "fixedFluxExtrapolatedPressureFvPatchScalarField" boundary
condition may be used for cases with or without body-forces to set the
pressure gradient to compensate not only for the body-force but also the
extrapolated "HbyA" which provides a second-order boundary condition for
pressure.  This is useful for a range a problems including impinging
flow, extrapolated inlet conditions with body-forces or for highly
viscous flows, pressure-induced separation etc.  To test this boundary
condition at walls in the motorBike tutorial case set

    lowerWall
    {
        type            fixedFluxExtrapolatedPressure;
    }

    motorBikeGroup
    {
        type            fixedFluxExtrapolatedPressure;
    }

Currently the new extrapolated pressure boundary condition is supported
for all incompressible and sub-sonic compressible solvers except those
providing implicit and tensorial porosity support.  The approach will be
extended to cover these solvers and options in the future.

Note: the extrapolated pressure boundary condition is experimental and
requires further testing to assess the range of applicability,
stability, accuracy etc.

Henry G. Weller
CFD Direct Ltd.