- number of fields was not set.
- interpolated surfaces incorrectly written for all formats

BUG: globalSum needed in the merit functions' directional derivative (fixes #1949)

Closes #1949

See merge request !403

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

Does not affect the current functionality of shape optimisation.

BUG: Wrong First extrapolated value of the merit function (fixes #1948)

Closes #1948

See merge request !402

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

Affected only the first optimisation cycle, if line search was enabled

If eta was not set explicitly, it was computed after evaluating the
directional derivative of the merit function, which was computed
wrongly, leading to an erroneous value of the extrapolated merit
function value.

BUG: collated format and writing of NURBS3DVolume CPs - see #1947

See merge request Development/openfoam!401

The if(Pstream::master()) clause in NURBS3DVolume::writeCpsInDict() was
causing the fileName of the regIOobject not to be allocated in all
processors, giving problems when masterUncollatedFileOperation::masterOp
was called by collatedFileOperation::writeObject for the mkDirOp.

- fixed indexing error (crashes under windows).
  No crash but still incorrect on other systems

- no limit to the number of ways of filing ptscotch libraries.
  RedHat/Fedora/CentOS should look for these directories:

      ptscotch include=/usr/include/openmpi-x86_64
      ptscotch library=/usr/lib64/openmpi/lib

  when MPI_ARCH_PATH=/usr/lib64/openmpi
  and mpicc --showme:compile yields -I/usr/include/openmpi-x86_64

ENH: limit output to 25 cell types per line for readability

- makes it easier to trace potential format errors etc

STYLE: downgrade warning about polyhedrals to a simple info message

- can assume that polyhedral support is widespread enough to not
  warrant a warning.

- had calculated boundaries (default) for the evaluated variables,
  which meant they retained their initialized values (usually Zero).

  This normally goes unnoticed, since the boundary values are largely
  irrelevant in the volField expressions. However, when applying
  functions that balk at a zero value - eg, log() - this raises a
  floating point exception.

  These boundary should be zeroGradient, since the evaluated variables
  correspond to the internalField only. Could continue to use
  calculated, but then need to set the calculated boundary values from
  the patch internal field manually.

- two occurrences where FatalIOErrorInLookup used exit(FatalError)
  instead of exit(FatalIOError), which caused the error messages
  to be lost.

Problem was initial value of zone (transported label) was
still 0. Fixed by properly checking for 'valid' state.

- on ArchLinux, everything is installed under /usr/include/scotch.

  The detection script uses SCOTCH_ARCH_PATH as an initial guess for
  ptscotch as well. However, on the second pass, it has an absolute
  value ("/usr") instead of a logical one ("scotch-system").
  This resulted in the logic for handling scotch+ptscotch subdirs
  being bypassed.

- the problem arises when output fields are missing on some
  processors.

  When the information is combined, the resulting HashTables can have
  different insertion orders. This poses an issue when there are hash
  key collisions and thus different chaining.

- Use sorted order.

Triggered when running e.g. postProcess

- specifying gradientExpr without a valueExpr, a missing fractionExpr
  should be treated as 0 (gradient only), not as 1 (value only)

ENH: improve sanity checks + evaluation short-cuts in exprMixedFvPatchField

- incorrect branching logic caused the "0" case to be ignored

- single entry point to handle negative expansions etc.
  Reduces typos and forgotten code (as per #1841)

- mostly only tripped when using fractional edge grading, since this
  is where the list reading is used. Overseen in commit 7da0b5be.

- the compiler reports

      Internal error loop: assertion failed:
      find_seq_in_lookup_table: seq_number not found
      (shared/cfe/edgcpfe/il.c, line 4118)

  Seems to be the same as the bug report
  https://community.intel.com/t5/Intel-C-Compiler/Internal-error-loop-assertion-failed-find-seq-in-lookup-table/td-p/1087603

This _should_ be fixed in icc 17.0 update 1, but appears to have
struck here as well.

- workaround: explicitly construct member elements.

- slipped in with changes to csvTableReader (commit 59ed3ba1) so
  only affects the 2006 version.

- adjust constructor to expect "componentColumns", but also accept
  "valueColumns" as 1912 and earlier-compatibility. This not only
  fixes the reported bug, but also ensure proper compatibility with
  older files.

ENH: use "refColumn" instead of "timeColumn" for csvTableReader

- consistent with the CSV Function1.
  Support 'timeColumn' as 1912 and earlier-compatibility.

TUT: remove unused table-reader entry

- experienced while reusing src/Pstream/Allwmake-mpi to create
  additional mpi-layers after installation. Since the copied sources
  are not located within the OpenFOAM source-tree (and/or the
  source-tree is non-writable), it should not and does not use the
  central build/WM_OPTIONS directory.

  However, when exploring for the appropriate local Make directory, it
  searched for the current '.' directory instead of checking for the
  resolved directory.

  This fails, since there is no src/Pstream/Make directory.
  Must check for src/Pstream/mpi/Make directory first!

- Adjust wclean to always remove a local build directory
  (Make/WM_OPTIONS) for additional safety.
  After which, attempt to remove central build/WM_OPTIONS version too.

- the various information queries MUST be executed with
  the '--no-print-directory' or risk polluting values
  in the information queries.

  This is mostly seen with the 'canCompile' test for tutorials running
  in parallel.