The patch field 'autoMap' and 'rmap' functions have been replaced with a
single 'map' function that can used to do any form of in-place
patch-to-patch mapping. The exact form of mapping is now controlled
entirely by the mapper object.
An example 'map' function is shown below:
void nutkRoughWallFunctionFvPatchScalarField::map
(
const fvPatchScalarField& ptf,
const fvPatchFieldMapper& mapper
)
{
nutkWallFunctionFvPatchScalarField::map(ptf, mapper);
const nutkRoughWallFunctionFvPatchScalarField& nrwfpsf =
refCast<const nutkRoughWallFunctionFvPatchScalarField>(ptf);
mapper(Ks_, nrwfpsf.Ks_);
mapper(Cs_, nrwfpsf.Cs_);
}
This single function replaces these two previous functions:
void nutkRoughWallFunctionFvPatchScalarField::autoMap
(
const fvPatchFieldMapper& m
)
{
nutkWallFunctionFvPatchScalarField::autoMap(m);
m(Ks_, Ks_);
m(Cs_, Cs_);
}
void nutkRoughWallFunctionFvPatchScalarField::rmap
(
const fvPatchScalarField& ptf,
const labelList& addr
)
{
nutkWallFunctionFvPatchScalarField::rmap(ptf, addr);
const nutkRoughWallFunctionFvPatchScalarField& nrwfpsf =
refCast<const nutkRoughWallFunctionFvPatchScalarField>(ptf);
Ks_.rmap(nrwfpsf.Ks_, addr);
Cs_.rmap(nrwfpsf.Cs_, addr);
}
Calls to 'autoMap' should be replaced with calls to 'map' with the same
mapper object and the patch field itself provided as the source. Calls
to 'rmap' should be replaced with calls to 'map' by wrapping the
addressing in a 'reverseFvPatchFieldMapper' (or
'reversePointPatchFieldMapper') object.
This change simplifies the creation of new patch fields and hence
improves extensibility. It also provides more options regarding general
mapping strategies between patches. Previously, general abstracted
mapping was only possible in 'autoMap'; i.e., from a patch to itself.
Now, general mapping is possible between different patches.
If the sequence of meshes are decomposed independently the number, order and
potentially type of processor patches is likely to change. Thus the processor
patches and patch fields must be replaced with those of the new mesh.
replacing the virtual functions overridden in engineTime.
Now the userTime conversion function in Time is specified in system/controlDict
such that the solver as well as all pre- and post-processing tools also operate
correctly with the chosen user-time.
For example the user-time and rpm in the tutorials/combustion/XiEngineFoam/kivaTest case are
now specified in system/controlDict:
userTime
{
type engine;
rpm 1500;
}
The default specification is real-time:
userTime
{
type real;
}
but this entry can be omitted as the real-time class is instantiated
automatically if the userTime entry is not present in system/controlDict.
The writeEntry form is now defined and used consistently throughout OpenFOAM
making it easier to use and extend, particularly to support binary IO of complex
dictionary entries.
"pos" now returns 1 if the argument is greater than 0, otherwise it returns 0.
This is consistent with the common mathematical definition of the "pos" function:
https://en.wikipedia.org/wiki/Sign_(mathematics)
However the previous implementation in which 1 was also returned for a 0
argument is useful in many situations so the "pos0" has been added which returns
1 if the argument is greater or equal to 0. Additionally the "neg0" has been
added which returns 1 if if the argument is less than or equal to 0.
Function1 is an abstract base-class of run-time selectable unary
functions which may be composed of other Function1's allowing the user
to specify complex functions of a single scalar variable, e.g. time.
The implementations need not be a simple or continuous functions;
interpolated tables and polynomials are also supported. In fact form of
mapping between a single scalar input and a single primitive type output
is supportable.
The primary application of Function1 is in time-varying boundary
conditions, it also used for other functions of time, e.g. injected mass
is spray simulations but is not limited to functions of time.