- only affected v2406

BUG: optimisation convergence criteria misbehave w/o a line search (fixes #3268)

Closes #3268

See merge request !709

When using the (optional) convergence criteria for the optimisation
loop, adherence to them is checked in the postUpdate phase of the update
of the design variables. If a line search is used, this means that the
flow equations have been solved anew using the new design variables and
the objective reduction check makes sense. If, however, no line search
is used, the objective reduction check happens immediately after the
update of the design variables and before re-solving the flow equations,
giving a reduction in the objective function and terminating the
optimisation loop prematurely.

Solved by calling the convergence check directly after the solution of
the flow equations, in case of a fixedStepUpdate

- the old logic relied on the presence/absence of a comma to decide
  whether to parse as fixed or free format. This logic is faulty when
  handling the final (trailing) entry and will generally lead to the
  last field being truncated when read in.
  Now the caller decides on fixed vs free.

FIX: inconsistent Nastran surface output format

- use FREE format by default. Previously had an odd mix of SHORT
  format when created without options and LONG format (as default)
  when created with format options.

OpenFOAM v2406

Closes #3183, #3149, #2588, #3177, #3146, #3161, #3128, #3163, #3175, #3171, #3115, #3144, #3137, #3138, #3133, #3125, #3126, #3123, #3119, #3105, #3106, #2024, #3102, #3082, #3090, #3089, #3085, and #3077

See merge request !695

ENH: Added new createViewFactors utility

See merge request !692

Andrew Heather authored 10 months ago and Kutalmış Berçin committed 10 months ago

Creates view factors for the view factor radiation model.

User-selectable models:

- raySearchEngine: model to generate rays, i.e. face-to-face connections
- viewFactorModel: model to compute the view factors

For visualisation, use:

- Write the view factors as a volume field

    writeViewFactors    yes;

- Write the rays using OBJ format:

    writeRays       yes; // default = no

Participating patches must be in the \c vewFactorWall group, i.e. using the
\c inGroups entry of the "\<case\>/polyMesh/boundary" file.

\verbatim
myPatch
{
    type            wall;
    inGroups        2(wall viewFactorWall);
    ...
}
\endverbatim

Reads:

- <constant>/viewFactorsDict : main controls
- <constant>/finalAgglom : agglomeration addressing (from faceAgglomerate)

Generates:

- <constant>/F : view factors (matrix)
- <constant>/mapDist : map used for parallel running
- <constant>/globalFaceFaces : face addressing

- bugfix for parallel gather of patch values with serial rendering

Martin Lichtmes authored 10 months ago and Mark OLESEN committed 10 months ago

- can be useful for various orientation-related geometry or mesh
  manipulations during pre-/post-processing:
  * combine with linearDirection to achieve better extrusion results.
  * orientation of transformations, blockMesh, result projections, ...

STYLE: minor code modernizations

Co-authored-by: Mark Olesen <>

SUBMODULE: update data- and turbulence-community plugins

- README updated to v2406, project-version updated to v2406

- adios: 2.9.2 -> 2.10.1
- paraview: 5.11.2 -> 5.12.1

Ancillary libs:

- hdf5:  1.14.4.3
- hypre: 2.23.0 -> 2.31.0
- petsc: 3.19.2 -> 3.21.2

REGRESSION: missing "value" handling for some surface fields (#3144)

See merge request Development/openfoam!691

Mark OLESEN authored 11 months ago and Kutalmış Berçin committed 10 months ago

- changes in 8a8b5db9 were overly aggressive.
  Only need to suppress "value" IO for empty patches types

BUG: adjointRotatingWallVelocity causes sensitivities to crash. Fixes #3180

Closes #3180

See merge request !690

- exprValueFieldTag is an extended version of exprValue,
  with additional Field/List uniformity handling

- the exprValueFieldTag reduce() method provides a more efficient
  method than using a regular combine operator. Since fields are
  usually non-uniform, will mostly only need the bitwise reduce and
  not a more expensive gather/combine.

ENH: output of exprValue (scalar type) now includes '.'

- prevents scalar/label ambiguity for values like '100.0', which would
  otherwise be written as '100' and thus interpreted as a label value
  when re-reading.

Left out original files