- in some cases, additional dictionary inputs are useful for extending
the input parameters or functionality of dynamic coded conditions.
Typically this can be used to provide a simple set of dictionary
inputs that are used to drive specific code, but allows changing the
inputs without causing a recompilation.
Accessed with this type of code:
```
const dictionary& dict = this->codeContext();
```
boundary conditions and function objects:
* specify an additional codeContext dictionary entry:
```
codeContext
{
...
}
```
PatchFunction1:
* The code context dictionary is simply the dictionary used to specify
the PatchFunction1 coefficients.
To replicated persistant data, use local member static data.
Eg,
```
code
#{
// Persistent (Member) Data
static autoPtr<Function1<scalar>> baseVel;
static autoPtr<Function1<vector>> baseDir;
...
#}
```
fvOptions:
* currently not applicable
- meshTools include/library for many (most) coded items
- add PatchFunction1 include for coded BCs to provide ready access
to Function1 and PatchFunction1
- 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.
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".
