GitLab

BACKPORT: AllwmakeParseArguments prefix handling from v2012

- the generic constructor could be called twice in pointPatchField::New,
  which results in an attempt to transfer tokens twice.

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

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.

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

mattijs authored Sep 30, 2020 and Mark Olesen committed Sep 30, 2020

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

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

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

- backported fix from develop

COMP: incorrect variable names in PtrListOpsTemplates.C

- used fluidThermo::typeName instead of fluidThermo::dictName
  within the Cp() method.

- only checked if it started with '/' and not 'd:/' (for example).