- also now report any verbosity on stderr

- fix similar collated directories issue for foamRestoreFields

- incorrectly set BINARY format in the construction of the received
  data (a side-effect of the parameter ordering).

  Now use the same default parameters as IFstream and set the correct
  filename subsequent to construction.

In differing precisions the PrecisionAdaptor will copy
the input array element by element and this can trigger
NaN detection.

- the foamConfigurePaths script is quite simplistic and aggressive in
  what it changes. This was particularly evident when using it to
  change gcc/clang versions.

  Restructured the corresponding compiler settings to define default
  versions (eg, "default_gcc_version") that limits the scope of
  changes performed by foamConfigurePaths and makes it easier to
  understand if changing manually.

- the gcc c++/9 includes now inline strncpy, which obliterates
  the previous method of suppressing the warning.
  Now simply allocate additional space for the nul character.

COMP: silence some icc warnings

COMP: backport of updates for gcc-92 compilation

See merge request Development/openfoam!336

- indexing error in the output of values resulted in uniform output in
  most cases.

- allocation error for on-the-fly triangulation

ENH: changed decomposed storage from DynamicList to plain faceList for
clearer allocation control and better overhead

BUG: add switch for nu:DphitEff in kEpsilonPhitF (fixes #1560)

Closes #1560

See merge request Development/openfoam!329

    Including `nu` in `DphitEff` even though it is not present in (LUU:Eq. 17)
    provided higher level of resemblance to benchmarks for the tests considered,
    particularly for the peak skin friction (yet, pressure-related predictions
    were unaffected). Users can switch off `nu` in `DphitEff` by using
    `includeNu` entry in `kEpsilonPhitFCoeffs` in order to follow the
    reference paper thereat. `includeNu` is left `true` by default.
    See GitLab issue #1560,

  LUU: Laurence, D. R., Uribe, J. C., & Utyuzhnikov, S. V. (2005).

BUG: wrong bounding of sensitivity contituents in case of many control boxes (Fixes #1549)

Closes #1549

See merge request Development/openfoam!325

When more than one volumetric B-Splines control boxes are present, the
sensitivity constituents corresponding to the non-active design
variables were not bounded(zeroed) correctly. The resultant
sensitivities, used in the optimization, were bounded correctly, so this
was more a bug pertaining to the output file of the sensitivities rather
than a functional one.

BUG: continuation of updateMethods with empty activeDesignVariables (#1540)

See merge request Development/openfoam!322

Vaggelis Papoutsis authored 5 years ago and Andrew Heather committed 5 years ago

When activeDesignVariables are not set explicitly, all design variables
are treated as active. These were allocated properly when starting from
0 but not when starting from an intermediate optimisation cycle
(e.g. running 5 optimisation cycles, stopping and restarting).

TUT: added a new tutorial including the restart of an optimisation run
to help identify future regression

BUG: writeMorpherCPs expects a controlBoxes entry (#1538)

See merge request Development/openfoam!321

Vaggelis Papoutsis authored 5 years ago and Andrew Heather committed 5 years ago

The controlBoxes wordList was removed from NURBS3DVolume in the
pre-release phase but writeMorpherCPs was not updated accordingly.

TUT: added the invocation of writeMorpherCPs in one of the tutotials to
help identify future regression

BUG: Wrong FatalIOError message in displacementMethod and optMeshMovement (#1537)

See merge request Development/openfoam!320

Vaggelis Papoutsis authored 5 years ago and Andrew Heather committed 5 years ago

- The core of the FatalIOError message was not printed due to exiting
  with FatalError instead of FatalIOError
- Changed the TypeName in all derived classes of displacementMethod so
  that the toc printed by the FatalIOError corresponds to what the user
  should add in dynamicMeshDict

    When a contact resistance is used the T field on each coupled
    patch is different due to the thermal resistance. Thus, instead
    of solving for a unique Tw at the wall, we solve for Tw1 at one side
    then, the Tnbr internal becomes Tw2, which is the T of the nbr
    patch.

Many possibilities:
- use as a simple calculator with vectors, tensors etc.
- test validity of expression syntax

As a calculator:

    foamCalc  '(vector(1,2,3) ^ vector(4,5,6)) * sqrt(34)'

The same, but with debugging:

    foamCalc -debug-switch fieldExpr=6 \
        'mag((vector(1,2,3) ^ vector(4,5,6))) * sqrt(34)'

- previously just reported gcc/clang versions, but these are not
  necessarily the ones actually being used (eg, clang-9 vs clang).
  Now use the path from `wmake -show-path-cxx` to improve the accuracy,
  and also support other compiler types.

Integration inter track foam

See merge request Development/openfoam!310