BUG: fix yPlus predictions of nut wall functions

See merge request !484

- previously OpenFOAM library paths were set before adding in
  MPI-specific elements. However, this may mask some libraries.

  |  New library order  |  Old library order  |
  |---------------------|---------------------|
  |  user-lib (serial)  |  various 3rd-party  |
  |  site-lib (serial)  |  foam-lib (mpi)     |
  |  foam-lib (mpi)     |  ext-lib (mpi)      |
  |  foam-lib (serial)  |  system mpi-libs    |
  |  ext-lib  (mpi)     |  user-lib (serial)  |
  |  ext-lib  (serial)  |  site-lib (serial)  |
  |  various 3rd-party  |  foam-lib (serial)  |
  |  system mpi-libs    |  ext-lib (serial)   |
  |  dummy              |  dummy              |

- provisions for alternative groupings of zones

- extend indices() for boundary meshes to handle wordRes as well

- use dictionary methods directly in LduMatrix::solver::readControls.
  Deprecate the redundant LduMatrix::solver::readControl helper-function

- define solver log-level outside of the loop,
  narrow log flag to int.

- reinstate API-compatible parameters for SolverPerformance

- allows reuse of an int64_t scotch library with label-size 32
  and/or label-size 64.

COMP: prefer scotch/metis/kahip libraries with label-size qualifiers

- as noted in #2200, mpirun may insert mpi libraries higher in the
  library loader which can cause masking of our ThirdParty libraries
  of the same name. With scotch (for example), the operating system
  may have an int32 version installed but we have an int64 version
  compiled under ThirdParty. Runing in serial is fine, but in parallel
  we resolve to the (incorrect) system version due to the adjustments
  in mpirun.

- adjust the ThirdParty make scripts to also create corresponding
  links (eg, 'ln -s libscotch.so libscotch-int64.so') and prefer
  linkage with these qualified libraries.

    Eg,  -L$(SCOTCH_LIB_DIR) -lscotch$(SCOTCH_LIBNAME_SUFFIX)

  this prevent accidental runtime linkage with the system versions.

STYLE: simplify scotch interface code by using local functions

- allows reuse similar to refPtr for wrapping different content.

- additional control for when contents are copied back,
  instead of waiting for the adaptor to go out of scope.

  Eg,

  if (adaptor.active())
  {
      adaptor.commit();
      adaptor.clear();
  }

- static ConstPrecisionAdaptor::get method renamed to 'select' as a
  better description of its purpose and avoid confusion with
  non-static 'get' method.

  Was previously only used within GAMGPreconditioner, but even there
  it is better just to use the ConstPrecisionAdaptor directly.

For cases where the number of injectors exceeded the number of parcels to
inject, processing the injectors sequentially led to not all injector locations
being active and yielding non-physical spatial distributions.

Improve the Lagrangian distribution models

See merge request !426

Previous naming conventions for input variables in the
normal, multiNormal, RosinRammler, and massRosinRammler
distributions were heuristic and did not reflect
the de facto conventions being used in statistics.

BUG: distributionModel: disallow any distribution
where input min is equal to input max

ENH: distributionModel: ensure execution of check() at ctor level

addZones: specifies the name instead of synthesising

ENH: enable custom input of U for devRhoReff and devReff

See merge request !479

Kutalmış Berçin authored 3 years ago and Andrew Heather committed 3 years ago

Previously, for basic incompressible and compressible simulations,
the "force" function object has not been using the user-specified "UName"
for the "devRhoReff" computation (affecting the tangential component),
but using the "U" of the latest available step. In contrast,
the user-specified "pName" has always been being used correctly.

This has been causing issues for users when they wish to use a specific
"UMean" field in various force and forceCoeff function object computations.