There are now three possible code entries for the scalarCodedSource,
vectorCodedSource, etc..., fvOptions. These are `codeAddSup` for basic
sources, `codeAddRhoSup` for compressible sources, and
`codeAddAlphaRhoSup` for phase (compressible) sources.
Previously `codeAddSup` was used for both basic and compressible
sources, and phase sources were not implemented. This meant that whilst
a compressible source could be created, it could not make use of the
`rho` argument or the basic source function would fail to compile.
Most fvOptions change the state of the fields and equations they are applied to
but do not change internal state so it makes more sense that the interface is
const, consistent with MeshObjects. For the few fvOptions which do maintain a
changing state the member data is now mutable.
For example in the new tutorial case:
tutorials/incompressible/pimpleFoam/laminar/pitzDailyPulse
a cosine bell velocity pulse is specified at the inlet by directly defining the
code for it:
inlet
{
type uniformFixedValue;
uniformValue coded;
name pulse;
codeInclude
#{
#include "mathematicalConstants.H"
#};
code
#{
return vector
(
0.5*(1 - cos(constant::mathematical::twoPi*min(x/0.3, 1))),
0,
0
);
#};
}
which is then compiled automatically and linked into the running pimpleFoam
dynamically and executed to set the inlet velocity.
Currently these deleted function declarations are still in the private section
of the class declarations but will be moved by hand to the public section over
time as this is too complex to automate reliably.
The dynamic code functionality has been generalised so that the names of
the code entries in the specifying dictionary can be set by the caller.
This means that functions which utilise dynamic code but use different
entry names (e.g., codedFunctionObject uses codeExecute, codeEnd,
etc..., instead of code) now function correctly. The differently named
entries now form part of the library hash, and re-building triggers
appropriately as they are modified.
The construction of some patch fields has been corrected so that the
patchType setting always propagates on mapping, IO, clone, etc...
Dictionary and mapping-based patch field constructors now call the
corresponding constructor from the base class, regardless of whether
dictionary settings or mapping are actually needed.
A "mappingRequired" flag has been added to some of the base constructors
in order to prevent unecessary mapping of field data and retain the
previous level of optimisation.
Resolves bug report https://bugs.openfoam.org/view.php?id=3144
Replaced the 'postProcess' argument to the 'write' and 'execute'
functions with the single static member 'postProcess' in the
functionObject base-class.
codedFunctionObject: Added the "codeWrite" entry
for the "write" function for consistency.
The previous method of using the "code" entry for the "write"
function was inconsistent and very confusing.
- Avoids the need for the 'OutputFilterFunctionObject' wrapper
- Time-control for execution and writing is now provided by the
'timeControlFunctionObject' which instantiates the processing
'functionObject' and controls its operation.
- Alternative time-control functionObjects can now be written and
selected at run-time without the need to compile wrapped version of
EVERY existing functionObject which would have been required in the
old structure.
- The separation of 'execute' and 'write' functions is now formalized in the
'functionObject' base-class and all derived classes implement the
two functions.
- Unnecessary implementations of functions with appropriate defaults
in the 'functionObject' base-class have been removed reducing
clutter and simplifying implementation of new functionObjects.
- The 'coded' 'functionObject' has also been updated, simplified and tested.
- Further simplification is now possible by creating some general
intermediate classes derived from 'functionObject'.
Rather than requiring each functionObject to handle failed construction
internally (using the active_ flag) the static member function "viable"
is provided which returns true if construction of the functionObject is
likely to be successful. Failed construction is then handled by the
wrapper-class which constructs the functionObject,
e.g. "OutputFilterFunctionObject".
