- 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
- Favour use of argList methods that are more similar to dictionary
method names with the aim of reducing the cognitive load.
* Silently deprecate two-parameter get() method in favour of the
more familiar getOrDefault.
* Silently deprecate opt() method in favour of get()
These may be verbosely deprecated in future versions.
- Eg, with surface writers now in surfMesh, there are fewer libraries
depending on conversion and sampling.
COMP: regularize linkage ordering and avoid some implicit linkage (#1238)
- naming similar to objectRegistry, with unambiguous resolution.
The lookup() methods have different return types depending on the
calling parameter.
STYLE: use IOobjectListTemplates.C for implementations
- previously included as local definition within IOobjectList.C,
but will be adding more templated methods soon.
- adjust parameters (eg, matchName instead of matcher) to show their
function
ENH: handle objectRegistry::names<void>(...)
- this is equivalent to no Type restriction, and can be used when
filtering names. Eg,
obr.names<void>(wordRe..);
- With argList::noFunctionObjects() we use the logic added in
4b93333292 (issue #352)
By removing the '-noFunctionObjects' option, we automatically
suppress the creation of function-objects via Time (with argList
as a parameter).
There is generally no need in these cases for an additional
runTime.functionObjects().off() statement
Use the argList::noFunctionObjects() for more direct configuration
and reduce unnecessary clutter in the -help information.
In previous versions, the -noFunctionObjects would have been redundant
anyhow, so we can also just ignore it now instead.
General:
* -roots, -hostRoots, -fileHandler
Specific:
* -to <coordinateSystem> -from <coordinateSystem>
- Display -help-compat when compatibility or ignored options are available
STYLE: capitalization of options text
- both autoPtr and tmp are defined with an implicit construct from
nullptr (but with explicit construct from a pointer to null).
Thus is it safe to use 'nullptr' when returning an empty autoPtr or tmp.
- use succincter method names that more closely resemble dictionary
and HashTable method names. This improves method name consistency
between classes and also requires less typing effort:
args.found(optName) vs. args.optionFound(optName)
args.readIfPresent(..) vs. args.optionReadIfPresent(..)
...
args.opt<scalar>(optName) vs. args.optionRead<scalar>(optName)
args.read<scalar>(index) vs. args.argRead<scalar>(index)
- the older method names forms have been retained for code compatibility,
but are now deprecated
- This provides a mechanism for moving mesh patches based on external
input (eg, from an external structures solver). The patch points are
influenced by the position and rotation of the lumped points.
BC: lumpedPointDisplacementPointPatchVectorField
Controlling mechanisms:
- externalCoupler
for coordinating the master/slave
- lumpedPointMovement
manages the patch-points motion, but also for extracting forces/moments
- lumpedPointState
represents the positions/rotations of the controlling points
Utils:
- lumpedPointZones
diagnostic for visualizing the correspondence between controlling
points and patch faces
- lumpedPointMovement
Test that the patch motion is as desired without invoking moveMesh.
With the -slave option, return items from a precalculated table
for the lumpedPointDisplacementPointPatchVectorField BC.
