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
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.
- Added function returning the underlaying surface sensitivities
- Added boolean to control whether to write the underlaying sensitivity
map (defaults to false)
Encapsulates all terms that are common in both E(SI) and FI
formulations, like direct sensitivities and sensitivities due to
primal boundary conditions. Added the latter to all derived sensitivity
types, except for sensitivity maps.
Same as adjointWallVelocity but also returns the contribution
of the differentiation of the rotatingWallVelocity BC wrt the
face centres, to be added to the sensitivity derivatives.
Main reason was the insertion of a templated virtual function
returning the contribution of the differentiation of the primal
boundary condition, in the case the latter directly depends on a
a geometric quantity (e.g. rotatingWallVelocity).
Example usage:
removeParcels1
{
type removeParcels;
log yes;
resetOnWrite no;
resetOnStart no;
faceZones (cycLeft cycRight);
}
Number and mass of particles removed are written to file
to geometricVoF
sampledInterface was linked to interfaceProperties thorugh geometricVoF,
and interfaceProperties created a conflict on surfaceTension table
when linked in the reactingEuler solvers by the sampling lib
Example usage:
cloudFunctions
{
WeberNumber1
{
type WeberNumber;
}
}
This will calculate and write the Weber number field as a 'standard'
cloud field, available for post-processing alongside other lagrangian
fields in the lagrangian/<cloudName> directory.
ENH: add log FO
ENH: improve log with scale, and offset entries
BUG: ensure extrueMesh does not fail in parallel with wedge extrusion
BUG: add missing clone and mapping funcs to copiedFixedValue, fixedMultiPhaseHeatFlux
ENH: meshToMesh0::cellAddressing slight speed up for some geometries
BUG:0003495: Divide-by-zero in SHF particle break-up model
BUG:0003492: The formula in the OF is inconsistent with the Rosin-Rammler distribution theory formula
- replace ':' scoping with IOobject::scopedName(), which automatically
uses '_' for Windows compilations where the ':' is a meta-character
(drive separator)
- apply similar local change for the momentum function object.
*** This topic will be revisited in the future ***
Please refer to the header file documentation for complete set of details.
ENH: add new fvOptions for ABL modelling
- atmAmbientTurbSource
- atmBuoyancyTurbSource
- atmCoriolisUSource
- atmLengthScaleTurbSource
- atmPlantCanopyTurbSource
- atmPlantCanopyUSource
- atmPlantCanopyTSource
- atmNutSource
ENH: add new boundary conditions for ABL modelling
with PatchFunction1 and TimeFunction1 support
- atmAlphatkWallFunction
- atmEpsilonWallFunction
- atmNutkWallFunction
- atmNutUWallFunction
- atmNutWallFunction
- atmOmegaWallFunction
- atmTurbulentHeatFluxTemperature
STYLE: change names of nutkAtmRoughWallFunction -> atmNutkWallFunction by
ensuring the bitwise backward compatibility
ENH: add new variable-scaling force computation method to actuationDiskSource
ENH: review actuationDiskSource and radialActuationDiskSource
ENH: add new function object, ObukhovLength
ENH: add new ABL tutorials/verifications
- verificationAndValidation/atmosphericModels/atmFlatTerrain
- verification with the Leipzig field experiment
- illustration of precursor/successor field mapping
- verificationAndValidation/atmosphericModels/atmForestStability
- verification with the Sweden field experiment
- update incompressible/simpleFoam/turbineSiting
1) Implementation of the compressibleIsoInterFOam solver
2) Implementation of a new PLIC interpolation scheme.
3) New tutorials associated with the solvers
This implementation was carried out by Henning Scheufler (DLR) and Johan
Roenby (DHI), following :
\verbatim
Henning Scheufler, Johan Roenby,
Accurate and efficient surface reconstruction from volume fraction data
on general meshes, Journal of Computational Physics, 2019, doi
10.1016/j.jcp.2019.01.009
\endverbatim
The integration of the code was carried out by Andy Heather and Sergio
Ferraris from OpenCFD Ltd.