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

A Helmholtz-like filter is applied to the original field of sensitivity
derivatives. The corresponding PDE is solved on the sensitivity patches,
using the finite area infrastructure. A smoothing radius is needed,
which is computed based on the average 'length' of the boundary faces,
if not provided by the user explicitly.

If an faMesh is provided, it will be used; otherwise it will be created
on the fly based on either an faMeshDefinition dictionary in system or
one constructed internally based on the sensitivity patches.

STYLE: use alias to mark partialFaceAreaWeightAMI deprecation after v2012

- return undefinedToken on error

STYLE: fix slicing of ITstream from dictionary lookup

- simplifies local toggling.

- centralize fileModification static variables into IOobject.
  They were previously scattered between IOobject and regIOobject

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

Does not affect the current functionality of shape optimisation.

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.

if useSolverNameForFields is set to true. This facilitates continuation.

fvOptionsAdjoint was needlessly duplicating a lot of the functionality
of fvOptions in order to add an interface for computing sensitivity
contributions emerging from fvOptions. To reduce this code duplication:

- fvOptionsAdjoint was removed
- the corresponding sensitivity contributions have moved to fvOptions through
  virtual functions (returning a zero contribution in the base so
  backwards compatibility is retained)
- all sensitivity classes that were using fvOptionsAdjoint have been
  modified appropriately
- all adjoint solvers are now grabbing a reference to an fvOptionList
  from the database instead of constructing an fvOptionsAdjointList

Hence, all fvOptions contributions to the adjoint equations
or the sensitivity derivatives can be given through system/fvOptions,
removing the need for separate sub-dictionaries within optimisationDict.

- Expanded the write function in the base class so that it can manage
  input coming from the derived ones. This reduces a lot of code
  duplication in the latter but keeps the functionality.
- Added a default width for all entries in the objective files.
- If a normalisation factor or a target is set, they are written on the
  header of the objective file.
- Cosmetic/code consistency changes in various files.

to files, if the corresponding adjoint solver has more than one
objectives.

- Added preLoop, loop and postLoop functions
- Added preIter, mainIter and postIter functions for each SIMPLE
  iteration
- Added addMomentumSource and addPressureSource virtual functions, to
  allow for additions by derived classes

fvOptions are no longer a member of incompressiblePrimalSolver but are
looked up from the registry in each iteration of each primal solver.
This means that the main system/fvOptions dictionary is read by ALL
instances of the primal solvers and the latter no longer have their
own fvOptions dict in optimisationDict. This is safe since each fvOption
is applied to a specific field and in case of many primal solvers, the
primal fields are named differently for each of them.

In addition, simple is now split in preLoop, loop and postLoop phase.
Furthermore, each SIMPLE iteration is broken down to
a preIter, mainIter and postIter phase, to allow for different behaviour
by derived classes.

to the primal and adjoint solver names

Part of the (E)SI shape sensitivities depends of grad(Ua) & nf computed
on the boundary. Up to now, the code was only computing the normal part
of grad(Ua), to avoid the potentially spurious tangential component
which is computed on the cell center and extrapolated to the boundary
faces. However, for some objectives that are strongly related to the
stresses (e.g. moment, stresses), including also the tangential part of
grad(Ua) is necessary for E-SI to replicate the outcome of FI.

Extensive testing on a number of objectives/cases showed
- No regression when including the tangential part
- Improved behaviour in some rare cases (moment, stresses)

Hence, the tangential part is now included by default. The previous code
behaviour can be replicated by setting the useSnGradInTranposeStresses
flag to true.

- controlPointsDefinition is now controled by a class with
  runTimeSelection.
- Added a new controlPointsDefinition option that translates, rotates
  and scales a given box. The required entries have the same meaning as
  in the Paraview 'Transform' filter, facilitating the transition between the
  visual placement of control boxes (e.g. in Paraview) and their setup
  in the code.
- Improved performance during the parameterization, sensitivity
  computation and grid displacement phases by re-using already computed
  basis functions.

in case useSolverNameForFields is set to true.
Used for multi-point optmisation runs.

since its behaviour can be replicated by the more general framework for
setting objective targets introduced in 6ee7bc66.

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.

Mark OLESEN authored 4 years ago and Vaggelis Papoutsis committed 4 years ago

- reduces some code complexity.

- since the context (laminar/RAS/LES) is already given by the
  sub-dictionary, it is redundant to use as prefix as well.

- silently support the longer names as compat methods

- constructs such as the following will no longer worked, but that is
  also a good thing.

     ptrlist.set(i, scalarField(nFaces, Zero));

  this called set(.., const tmp<scalarField>&), which meant under
  the hood:

     - create local temporary const scalarField&
     - wrap as const tmp&
     - use tmp::ptr(), to clone the const-ref

  This implies an additional allocation (for the const scalarField&)
  which is immediately discarded. Doubtful that compiler optimization
  would do anything.

- cleaner code, more similarity with unique_ptr

  Now
      if (ptr)
      if (!ptr)

  instead
      if (ptr.valid())
      if (!ptr.valid())

- with '&&' conditions, often better to check for non-null autoPtr
  first (it is cheap)

- check as bool instead of valid() method for cleaner code, especially
  when the wrapped item itself has a valid/empty or good.
  Also when handling multiple checks.

  Now
      if (ptr && ptr->valid())
      if (ptr1 || ptr2)

  instead
      if (ptr.valid() && ptr->valid())
      if (ptr1.valid() || ptr2.valid())

- less clutter using plain tests with the bool operator:

      (!ptr)  vs  (ptr.empty())
      (ptr)   vs  (!ptr.empty())

- same as FixedList<bool,3> for I/O

- since only pointers are stored, autoPtr is better fit than tmp