These new names are more consistent and logical because:
primitiveField():
primitiveFieldRef():
Provides low-level access to the Field<Type> (primitive field)
without dimension or mesh-consistency checking. This should only be
used in the low-level functions where dimensional consistency is
ensured by careful programming and computational efficiency is
paramount.
internalField():
internalFieldRef():
Provides access to the DimensionedField<Type, GeoMesh> of values on
the internal mesh-type for which the GeometricField is defined and
supports dimension and checking and mesh-consistency checking.
In order to simplify expressions involving dimensioned internal field it
is preferable to use a simpler access convention. Given that
GeometricField is derived from DimensionedField it is simply a matter of
de-referencing this underlying type unlike the boundary field which is
peripheral information. For consistency with the new convention in
"tmp" "dimensionedInteralFieldRef()" has been renamed "ref()".
When the GeometricBoundaryField template class was originally written it
was a separate class in the Foam namespace rather than a sub-class of
GeometricField as it is now. Without loss of clarity and simplifying
code which access the boundary field of GeometricFields it is better
that GeometricBoundaryField be renamed Boundary for consistency with the
new naming convention for the type of the dimensioned internal field:
Internal, see commit 4a57b9be2e
This is a very simple text substitution change which can be applied to
any code which compiles with the OpenFOAM-dev libraries.
Given that the type of the dimensioned internal field is encapsulated in
the GeometricField class the name need not include "Field"; the type
name is "Internal" so
volScalarField::DimensionedInternalField -> volScalarField::Internal
In addition to the ".dimensionedInternalField()" access function the
simpler "()" de-reference operator is also provided to greatly simplify
FV equation source term expressions which need not evaluate boundary
conditions. To demonstrate this kEpsilon.C has been updated to use
dimensioned internal field expressions in the k and epsilon equation
source terms.
The deprecated non-const tmp functionality is now on the compiler switch
NON_CONST_TMP which can be enabled by adding -DNON_CONST_TMP to EXE_INC
in the Make/options file. However, it is recommended to upgrade all
code to the new safer tmp by using the '.ref()' member function rather
than the non-const '()' dereference operator when non-const access to
the temporary object is required.
Please report any problems on Mantis.
Henry G. Weller
CFD Direct.
To be used instead of zeroGradientFvPatchField for temporary fields for
which zero-gradient extrapolation is use to evaluate the boundary field
but avoiding fields derived from temporary field using field algebra
inheriting the zeroGradient boundary condition by the reuse of the
temporary field storage.
zeroGradientFvPatchField should not be used as the default patch field
for any temporary fields and should be avoided for non-temporary fields
except where it is clearly appropriate;
extrapolatedCalculatedFvPatchField and calculatedFvPatchField are
generally more suitable defaults depending on the manner in which the
boundary values are specified or evaluated.
The entire OpenFOAM-dev code-base has been updated following the above
recommendations.
Henry G. Weller
CFD Direct
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.
When restarting form a previous calculation, the averaging is continuous or
may be restarted using the \c restartOnRestart option.
The averaging process may be restarted after each calculation output time
using the \c restartOnOutput option or restarted periodically using the \c
periodicRestart option and setting \c restartPeriod to the required
averaging period.
Example of function object specification:
\verbatim
fieldAverage1
{
type fieldAverage;
functionObjectLibs ("libfieldFunctionObjects.so");
...
restartOnRestart false;
restartOnOutput false;
periodicRestart false;
restartPeriod 0.002;
fields
(
U
{
mean on;
prime2Mean on;
base time;
window 10.0;
windowName w1;
}
p
{
mean on;
prime2Mean on;
base time;
}
);
}
\endverbatim
\heading Function object usage
\table
Property | Description | Required | Default value
type | type name: fieldAverage | yes |
restartOnRestart | Restart the averaging on restart | no | no
restartOnOutput | Restart the averaging on output | no | no
periodicRestart | Periodically restart the averaging | no | no
restartPeriod | Periodic restart period | conditional |
fields | list of fields and averaging options | yes |
\endtable
fvOptions are transferred to the database on construction using
fv::options::New which returns a reference. The same function can be
use for construction and lookup so that fvOptions are now entirely
demand-driven.
The abstract base-classes for fvOptions now reside in the finiteVolume
library simplifying compilation and linkage. The concrete
implementations of fvOptions are still in the single monolithic
fvOptions library but in the future this will be separated into smaller
libraries based on application area which may be linked at run-time in
the same manner as functionObjects.
Now solvers return solver performance information for all components
with backward compatibility provided by the "max" function which created
the scalar solverPerformance from the maximum component residuals from
the SolverPerformance<Type>.
The residuals functionObject has been upgraded to support
SolverPerformance<Type> so that now the initial residuals for all
(valid) components are tabulated, e.g. for the cavity tutorial case the
residuals for p, Ux and Uy are listed vs time.
Currently the residualControl option of pimpleControl and simpleControl
is supported in backward compatibility mode (only the maximum component
residual is considered) but in the future this will be upgraded to
support convergence control for the components individually.
This development started from patches provided by Bruno Santos, See
http://www.openfoam.org/mantisbt/view.php?id=1824
This had been used in functionObjects:
Info(log)<< "messages" << data << ....
in which it is not at all clear what the "log" argument does whereas
if (log) Info<< "messages" << data << ....
is totally clear and more efficient.
