- related to change c3571b7357 (does not affect 1912 or older).
Remnant check for data() should have used valid() method instead.
TUT: add fluxSummary cellZoneAndDirection to angledDuct/implicit
- For some cases it can be helpful to test if additional libraries can
be properly resolved.
This can be useful in scripts to test for additional capability:
if foamHasLibrary geometricVoF
then ...
fi
But also directly from the command-line to help resolve configuration
issues:
foamHasLibrary -verbose petscFoam
Could not load "petscFoam"
libpetsc.so.3.13: cannot open shared object file: No such file or directory
- when installed in-source, use PETSC_ARCH to find additional include
directory and the correct library directory
CONFIG: bump to new hypre version
- add -hint option for have_adios2, have_hypre, have_petsc
The function object now computes the acoustic pressure at a list of user
specified locations, or from the face centres of a user-supplied surface.
When operating on an input surface, the output can be written back to the
surface or as a list of point values.
Example of function object specification:
Curle1
{
type Curle;
libs ("libfieldFunctionObjects.so");
...
patches (surface1 surface2);
c0 330;
// Input - either points or surface
input points;
observerPositions ((0 0 0)(1 0 0));
//input surface;
//surface "inputSurface.obj"
// Output - either points or surface
output points;
//output surface;
//surfaceType ensight;
}
Where the entries comprise:
Property | Description | Required | Default value
type | Type name: Curle | yes |
p | Pressure field name | no | p
patches | Sound generation patch names | yes |
c0 | Reference speed of sound | yes |
input | Input type | yes |
observerPositions | List of observer positions (x y z) | no |
surface | Input surface file name | no |
output | Output type | yes |
surfaceType | Output surface type | no |
- the earlier implementation of externally controlled lumped point
motion (see merge request !120 and OpenFOAM-v1706 release notes) was
conceived for the motion of simple structures such as buildings or
simple beams. The motion controller was simply defined in terms of
an orientation axis and divisions along that axis.
To include complex structures, multiple motion controllers are
defined in terms of support points and connectivity.
The points can have additional node Ids associated with them, which
makes it easier to map to/from FEA models.
OLD system/lumpedPointMovement specification
--------------------------------------------
//- Reference axis for the locations
axis (0 0 1);
//- Locations of the lumped points
locations (0 0.05 .. 0.5);
NEW system/lumpedPointMovement specification
--------------------------------------------
// Locations of the lumped points
points
(
(0 0 0.00)
(0 0 0.05)
...
(0 0 0.50)
);
//- Connectivity for motion controllers
controllers
{
vertical
{
pointLabels (0 1 2 3 4 5 6 7 8 9 10);
}
}
And the controller(s) must be associated with the given
pointDisplacement patch. Eg,
somePatch
{
type lumpedPointDisplacement;
value uniform (0 0 0);
controllers ( vertical ); // <-- NEW
}
TUT: adjust building motion tutorial
- use new controllor definitions
- replace building response file with executable
- add updateControl in dynamicMeshDict for slowly moving structure
- use simpler decomposeParDict in tutorials, several had old
'boilerplate' decomposeParDict
- use simpler libs () format
- update surface sampling to use dictionary format
- Removed some unnecessary dynamicMeshDicts.
- Removed the writeActiveDesignVariables execution from the Allrun
scripts, since it is no longer necessary to execute it before
adjointOptimisationFoam.
- Updated the entries in dynamicMeshDict according to efbc9fc99.
for all objective functions.
- The normalization is useful for practically all update methods dealing
with constraints (e.g. SQP, MMA). The normalization factor can be either
given explicitly or, if not given, will be the value of the objective
function in the first optimisation cycle.
- The target value is useful when using the objective as a constraint in
constrained optimisation problems (e.g. drag - dragTarget). It should
only be used with update methods that understand the value of the
constraint (e.g. SQP, MMA) but not when the objective in hand is the
only objective of the optimisation problem. In such a case, a squared
objective should be used (e.g. sqr(drag - dragTarget))
- Objective now inherits from localIOdictionary and writes the mean
objective value under the uniform folder, each time mesh.write() is
called. This is crucial for getting the correct old merit function value
if the simulation is continued from a previous state and lineSearch is
used.
- Objectives are now computed and written even if the corresponding
adjoint solver is inactive. This, among others, is also essential for
getting the correct old merit function value in case of continuation.
- Writing of the objective function (and its mean, if present) history
has now moved to updatePrimalBasedQuantities, instead of the preLoop
part of the adjoint solvers. This was decided to get the objective
values to files, even if the adjoint solver is inactive. Arguably, an
even better place to write the objective functions would be the postLoop
part of the primal solvers, however this might cause multiple writes of
the objective value for the inner iterations of lineSearch, if one is
used.
Moved part common to all derived classes (e.g. update) to the base
class to avoid code duplication. Practically, only the protected
updateDesignVariables has to be overwritten in each derived class now.
steadyOptimisation was also affected in a minor way.
