- naming similarity with autoPtr, unique_ptr and other containers.
For UPtrList derivatives, this is equivalent to the existing
operator(). The read-only variant is also equivalent to the
single-parameter 'set(label)' method.
With PtrList<T> list(...) :
const T* ptr = list.get(10);
if (ptr)
{
ptr->method();
}
vs.
if (list.set(10))
{
list[10].method();
}
For HashPtrTable there is only a read-only variant which is equivalent
to testing for existence and for value.
With HashPtrTable<T> hash(...) :
const T* ptr = list.get("key");
if (ptr)
{
ptr->method();
}
vs.
if (list.found("key"))
{
// Fails on null pointer!!
list["key"].method();
}
Use of get() is largely a matter of taste or local coding requirements
- forwarding like the emplace() method, but overwriting existing
entries as required
- propagate similar changes to HashPtrTable
For example, with HashPtrTable<labelList> table(...) :
With 'insert' semantics
table.emplace("list1", 1000);
vs
if (!table.found("list1"))
{
table.set("list1", new labelList(1000));
}
or
table.insert("list1", autoPtr<labelList>::New(1000));
Note that the last example invokes an unnecessary allocation/deletion
if the insertion is unsuccessful.
With 'set' semantics:
table.emplace_set("list1", 15);
vs
table.set("list1", new labelList(15));
The fakeError function object emits FatalError at different stages (or
does nothing), which is useful for testing purposes (issue #1779).
Can request errors from constructor, execute and write methods.
- with '&&' conditions, often better to check for non-null autoPtr
first (it is cheap)
- check as bool instead of valid() method for cleaner code, especially
when the wrapped item itself has a valid/empty or good.
Also when handling multiple checks.
Now
if (ptr && ptr->valid())
if (ptr1 || ptr2)
instead
if (ptr.valid() && ptr->valid())
if (ptr1.valid() || ptr2.valid())
- libs() singleton method for global library handling
- explicit handling of empty filename for dlLibraryTable open/close.
Largely worked before, but now be more explicit about its behaviour.
- add (key, dict) constructor and open() methods.
More similarity to dimensionedType, Enum etc, and there is no
ambiguity with the templated open().
- construct or open from initializer_list of names
- optional verbosity when opening with auxiliary table,
avoid duplicate messages or spurious messages for these.
- basename and fullname methods (migrated from dynamicCode).
- centralise low-level load/unload hooks
- adjust close to also dlclose() aliased library names.
- 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
- 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
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
- missing minThreshold in activePressureForceBaffleVelocity
- update names of cyclics
- increase tolerance for zero-thickness baffles
- velocity field "U" instead of "UBet"
- viscosity field "nut" instead of "mut"
- overrides normal deltaT for testing accelerated motion.
Can be useful to test mesh motions with constant/dynamicMeshDict
entries (updateControl, updateInterval) where the mesh motion is
much slower than any of the fluid physics.
see commit 87bba9ae14
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.
ENH: add Test-EigenMatrix application
The new iterative eigen decomposition functionality is
derived from:
Passalacqua et al.'s OpenQBMM (openqbmm.org/),
which is mostly derived from JAMA (math.nist.gov/javanumerics/jama/).
- generates a vtk file in an ASCII, XML format (blockTopology.vtu).
More information than the equivalent obj file since it includes
connectivity, cell shapes and cell IDs (equivalent to the block
numbers).
- bundled of boolean values as a vector of 3 components with
element access using x(), y() and z() member functions.
It also has some methods similar to bitSet.
- Not derived from Vector or VectorSpace since it does not share very
many vector-like characteristics.
- support construct from initializer_list, which can help simplify
code with constant coefficients.
- add default constructor for polynomialFunction and Istream reading
to support resizable lists of polynomialFunction.
A default constructed polynomialFunction is simply equivalent to
a constant zero.
- no special IO handling for Polynomial required,
it is the same as VectorSpace anyhow.
The phase systems tables for multiphase solvers create conflict
between each other as they are defined in the same namespace and using
similar class names.
Therefore a special htc function object for reactingEulerSolver was
added (reactingEulerHtcModel), located under
src/phaseSystemModels/reactingEulerFoam/functionObjects/
This commit includes the following:
- Relocate solvers/reactingEulerFoam functionObjects to
src/phaseSystemModels
- Remove links for fieldFunctionObject to multiphase libs to avoid
conflicts
- New FO for htc for reactingEulerFoam called reactingEulerHtcModel
- previously introduced `getOrDefault` as a dictionary _get_ method,
now complete the transition and use it everywhere instead of
`lookupOrDefault`. This avoids mixed usage of the two methods that
are identical in behaviour, makes for shorter names, and promotes
the distinction between "lookup" access (ie, return a token stream,
locate and return an entry) and "get" access (ie, the above with
conversion to concrete types such as scalar, label etc).
