- affects ensightSurfaceReader only.
If there are no `*` characters, protect against replacement.
Otherwise it would attempt to replace a zero-length string with
a single `0`, which results in prepending the name.
STYLE: ensightSurfaceReader constructor explicit
- start of work to create a 1-to-1 face mapping across AMI patches
- faces are inserted according to the AMI addressing based on Horacio's method
- removed 'updated' flag and reworked some demand driven updates
- updated to handle 'walking' through baffles
- use bitSet instead of boolList
- moved update of meshPhi to movePoints() functions at fvPatch level
- moved scaling of areas to movePoints() functions at fvPatch level
- rehomed topology change code to own file
- added warning re: geometry construction
ACMI
- split srcMask into srcMask and srcAreaMask
- former in range 0-1, and latter has bounding or tol to (1-tol) to avoid
sigFpe's
- 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
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.
