- provides a more succinct way of writing
{fa,fv}PatchField<Type>::patchInternalField(*this)
as well as a consistent naming that can be used for patches derived
from valuePointPatchField
ENH: readGradientEntry helper method for fixedGradient conditions
- simplifies coding and logic.
- support different read construct modes for fixedGradient
- marks if the value is considered to be independent of 'x'.
Propagate into PatchFunction1 instead ad hoc checks there.
- adjust method name in PatchFunction1 to 'whichDb()' to reflect
final changes in Function1 method names.
ENH: add a Function1 'none' placeholder function
- This is principally useful for interfaces that expect a Function1
but where it is not necessarily used by a particular submodel.
TUT: update Function1 creation to use objectRegistry
- previously had codeAddSup used for both incompressible and
compressible source terms. However, it was not actually possible to
use it for compressible sources since any references to the 'rho'
parameter would cause a compilation error for the incompressible case.
Added 'codeAddSupRho' to distinguish the compressible case.
User must supply one or both of them on input.
- 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
- easier support for non-mandatory functions.
In some boundary conditions it can be desirable to support
additional functions, but not necessarily require them. Make this
easier to support with a Function1, PatchFunction1 NewIfPresent()
selector.
- support for compatibility lookups
- harmonize branching logic and error handling between Function1 and
PatchFunction1.
ENH: refactor a base class for Function1, PatchFunction1
- includes base characteristics, patch or scalar information
ENH: additional creation macros
- makeConcreteFunction1, makeConcretePatchFunction1Type for adding a
non-templated function into the correct templated selection table.
makeScalarPatchFunction1 for similarity with makeScalarFunction1
- 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".
