- adjust naming of quaternion 'rotationSequence' to be 'eulerOrder'
to reflect its purpose.
- provide rotation matrices directly for these rotation orders in
coordinateRotations::euler for case in which the rotation tensor
is required but not a quaternion.
Modified revert of commit 6c6f777bd5.
- The "alphaContactAngleFvPatchScalarField" occurs in several
places in the code base:
- as abstract class for two-phase properties
- in various multiphase solvers
To resolve potential linking conflicts, renamed the abstract class
as "alphaContactAngleTwoPhaseFvPatchScalarField" instead.
This permits potential linking of two-phase and multi-phase
libraries without symbol conflicts and has no effect on concrete
uses of two-phase alphaContactAngle boudary conditions.
- support move insert/set and emplace insertion.
These adjustments can be used for improved memory efficiency, and
allow hash tables of non-copyable objects (eg, std::unique_ptr).
- extend special HashTable output treatment to include pointer-like
objects such as autoPtr and unique_ptr.
ENH: HashTable::at() method with checking. Fatal if entry does not exist.
All remote contributions to interpolation stencils now
get added as 'processor' type lduInterfaces. This guarantees
a consistent matrix, e.g. initial residual is normalised to 1.
Second change is the normalisation of the interpolation discretisation
which uses the diagonal from the unmodified equation. This helps
GAMG.
- for codedFunctionObject and CodedSource the main code snippets
were not included in the SHA1 calculation, which meant that many
changes would not be noticed and no new library would be compiled.
As a workaround, a dummy 'code' entry could be used solely for the
purposes of generating a SHA1, but this is easily forgotten.
We now allow tracking of the dynamicCodeContext for the coded
objects and append to the SHA1 hasher with specific entries.
This should solve the previous misbehaviour.
We additionally add information about the ordering of the code
sections. Suppose we have a coded function object (all code
segments are optional) with the following:
codeExecute "";
codeWrite #{ Info<< "Called\n"; #};
which we subsequently change to this:
codeExecute #{ Info<< "Called\n"; #};
codeWrite "";
If the code strings are simply concatenated together, the SHA1 hashes
will be identical. We thus 'salt' with their semantic locations,
choosing tags that are unlikely to occur within the code strings
themselves.
- simplify the coded templates with constexpr for the SHA1sum
information.
- Correct the CodedSource to use 'codeConstrain' instead of
'codeSetValue' for consistency with the underlying functions.
- amalgamate dlSym() and dlSymFound() into a single dlSymFind() backend
with optional 'required' argument. This makes it possible to
query and assign at once.
- previously would have different SHA1 depending on whether the
string was a C-string, a C++-string or if the SHA1 was calculated
directly or via the OSHA1stream.
- SHA1("string")
- OSHA1stream << "string";
- OSHA1stream << string("string");
By avoiding string quoting on output, they now all deliver the same
result. This also means that the following will no longer change the SHA1
content, since it does not add anything:
osha<< string() << string() << string() << string();
This would have previously add a pair of double quotes each time!
- 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)
