- The findObject() methods are template-typed and used to locate a
particular Type/name combination.
Eg,
volScalarField* ptr = obr.findObject<volScalarField>("xyz");
- The findIOobject() methods are un-typed and use the name only.
Eg,
regIOobject* ptr = obr.findIOobject("xyz");
The typed versions will be most commonly used, but the un-typed lookup
can be useful in a templating.
- Simplified findObject* methods to use findIOobject* as the backend.
- similar to what erase() does, but as a mutable operation (#1180)
- replace basicThermo lookupAndCheckout (commit 880c98757d) with
the new objectRegistry::checkOut() method.
- implemented as lazy evaluation with an additional update() method.
This avoids unnecessary changes until the values are actually
required.
- apply mesh motion changes for momentum, volFieldValue,
specieReactionRates function objects
- changed ensightOutput from a class solely comprising static methods to
a namespace and added in sub-namespaces Detail and Serial.
This makes it easier to "mix-in" functions at different levels.
Refactored and combined some serial/parallel code where possible.
The general ensightOutput namespace has now shifted to be in the
fileFormats lib, while leaving volField outputs in the conversion lib
and cloud outputs in the lagrangian-intermediate lib.
The ensightCloud namespace is now simply folded into the new
ensightOutput namespace.
These changes clean up some code, reduce fragmentation and
duplication and removes the previous libconversion dependency for
sampling.
- use int for ensight nTypes constexpr
Note: issue #1176 is unaffected except for the change in file name:
ensightOutputTemplates.C -> ensightOutputVolFieldTemplates.C
- improved the selection mechanism to include using a bitSet
cell selection (more efficient and convenient).
Use templated implementation internally to remove the previous
reliance on a NullObject.
Eg,
#define FOAM_CONFIGURED_PROJECT_ETC "/usr/share/openfoam/etc"
This provides some easy to file patching locations, but is not yet
integrated in the build system at all.
- in some circumstances we need to pass a bool value upwards to the
caller and know if the true/false value was set based on real input
or is a default value.
Eg, in the object::read() we might normally have
enabled_(dict.readIfPresent(key, true));
but would lose information about why the value is true/false.
We can change that by using
enabled_(dict.readIfPresent<Switch>(key, Switch::DEFAULT_ON));
After which we can use this information is testing.
if
(
child.enabled().nonDefault()
? child.enabled()
: parent.enabled()
)
{ ... }
And thus enable output if the parent requested it explicitly or by
default and it has not been explicitly disabled in the child.
No difference when testing as a bool and the text representation
of DEFAULT_ON / DEFAULT_OFF will simply be "true" / "false".
ENH: add construction of Switch from dictionary (similar to Enum)
- in addition to managing different vendors and versions, it may also
be necessary or desirable to have a particular variant
(eg, profiling, release, etc).
Devise a new meaningful name for the variant and create a
corresponding wmake rule.
Eg, SYSTEMOPENMPI-profiling with a corresponding
"wmake/rules/linux64Gcc/mplibSYSTEMOPENMPI-profiling" file
that has suitable content for your system.
CONFIG: intel-mpi use intel64/ paths only for config and wmake rules (#1153)
- previously adjusted the config files, but missed the changes
required for the wmake rules too.
Now simply migrate to using "intel64/{include,bin,lib}"
instead of the older naming "{include,bin,lib}64"
These changes work since at least intel-mpi 2015 (5.x), but possibly
earlier as well
