- argList::envExecutable() static method.
This is identical to getEnv("FOAM_EXECUTABLE"), where the name of
the executable has typically been set from the argList construction.
Provides a singleton access to this value from locations that
do not have knowledge of the originating command args (argList).
This is a similar rationale as for the argList::envGlobalPath() static.
- additional argList::envRelativePath() static method.
- make -dry-run handling more central and easier to use by adding into
argList itself.
STYLE: drop handling of -srcDoc (v1706 option)
- replaced with -doc-source for 1712 and never used much anyhow
- wrap command-line retrieval of fileName with an implicit validate.
Instead of this:
fileName input(args[1]);
fileName other(args["someopt"]);
Now use this:
auto input = args.get<fileName>(1);
auto other = args.get<fileName>("someopt");
which adds a fileName::validate on the inputs
Because of how it is implemented, it will automatically also apply
to argList getOrDefault<fileName>, readIfPresent<fileName> etc.
- adjust fileName::validate and clean to handle backslash conversion.
This makes it easier to ensure that path names arising from MS-Windows
are consistently handled internally.
- dictionarySearch: now check for initial '/' directly instead of
relying on fileName isAbsolute(), which now does more things
BREAKING: remove fileName::clean() const method
- relying on const/non-const to control the behaviour (inplace change
or return a copy) is too fragile and the const version was
almost never used.
Replace:
fileName sanitized = constPath.clean();
With:
fileName sanitized(constPath);
sanitized.clean());
STYLE: test empty() instead of comparing with fileName::null
- 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.
General:
* -roots, -hostRoots, -fileHandler
Specific:
* -to <coordinateSystem> -from <coordinateSystem>
- Display -help-compat when compatibility or ignored options are available
STYLE: capitalization of options text
- 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.
