- tie the MPI rules to the base compiler type *without* its version.
  Eg, linux64Gcc (which exists) instead of linux64Gcc81

- was using st_atim instead of st_mtim for the nanoseconds

- value of followLink was being ignored (it was always being followed).

This thermo is used with multiComponentMixture in rhoThermo type

mattijs authored 7 years ago and Mark OLESEN committed 7 years ago

- occurred when the initial mesh distribution was missing cells on
  some processors.

- using const reference to temporary was failing.  Remedy by using a
  direct copy, which is a reasonable solution since surfZone content
  is quite minimal.

- downgrades some diagnostics about nonconformant code from errors to
  warnings. Oddly enough, the errors actually arise from STL library
  elements shipped with gcc itself. Affects kahip compilation with
  gcc-6, gcc-7

The minimum number of particles per parcel can now be set in the
injection model input, e.g.:

    model1
    {
        type            ...;
        massTotal       ...;
        parcelBasisType ...;
        minParticlesPerParcel 1; <-- new optional entry
        SOI             ...;
        ...

Uses a value of 1 by default if the entry is not present.  The value of
1 is generally recommended and beneficial for coupled cases where small
time steps can lead to the injection of too many parcels and subsequently
greatly over-predict the particle source contributions (momentum, heat,
mass transfer etc)

The non-dimensional table takes non-dimensional U as entry, not flow rate

- runTimeModifiable change to the dictionary not being propagated to
  the underlying functionObjects

- problems when the cloud was not available on all processors.

- NB: ensight measured data only allows a single cloud, but
  foamToEnsight writes all clouds.

- these were previously taken from region-local directories
  (eg, constant/region/triSurface), but this becomes difficult to
  manage when there are many files and regions.

- The central InfoSwitch "writeLagrangianPositions" allows writing an
  additional Lagrangian "positions" file, but these were not being
  written by reconstructPar. These are now also written in reconstructPar
  if the central writeLagrangianPositions InfoSwitch is enabled.

NOTES

- "positions" are reconstructed from the processors "coordinates" file

- decomposePar will not attempt to create or redistribute any
  "positions" files