Replaced the 'postProcess' argument to the 'write' and 'execute'
functions with the single static member 'postProcess' in the
functionObject base-class.
In most boundary conditions, fvOptions etc. required and optional fields
to be looked-up from the objectRegistry are selected by setting the
keyword corresponding to the standard field name in the BC etc. to the
appropriate name in the objectRegistry. Usually a default is provided
with sets the field name to the keyword name, e.g. in the
totalPressureFvPatchScalarField the velocity is selected by setting the
keyword 'U' to the appropriate name which defaults to 'U':
Property | Description | Required | Default value
U | velocity field name | no | U
phi | flux field name | no | phi
.
.
.
However, in some BCs and functionObjects and many fvOptions another
convention is used in which the field name keyword is appended by 'Name'
e.g.
Property | Description | Required | Default value
pName | pressure field name | no | p
UName | velocity field name | no | U
This difference in convention is unnecessary and confusing, hinders code
and dictionary reuse and complicates code maintenance. In this commit
the appended 'Name' is removed from the field selection keywords
standardizing OpenFOAM on the first convention above.
- 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".
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()".
Non-const access to the internal field now obtained from a specifically
named access function consistent with the new names for non-canst access
to the boundary field boundaryFieldRef() and dimensioned internal field
dimensionedInternalFieldRef().
See also commit a4e2afa4b3
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 a25a449c9e
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.
//- Disallow default shallow-copy assignment
//
// Assignment of UList<T> may need to be either shallow (copy pointer)
// or deep (copy elements) depending on context or the particular type
// of list derived from UList and it is confusing and prone to error
// for the default assignment to be either. The solution is to
// disallow default assignment and provide separate 'shallowCopy' and
// 'deepCopy' member functions.
void operator=(const UList<T>&) = delete;
//- Copy the pointer held by the given UList.
inline void shallowCopy(const UList<T>&);
//- Copy elements of the given UList.
void deepCopy(const UList<T>&);
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.
This function object calculates mole-fraction fields from the mass-fraction
fields of the psi/rhoReactionThermo and caches them for output and further
post-processing.
The names of the mole-fraction fields are obtained from the corresponding
mass-fraction fields prepended by "X_"
Example of function object specification:
moleFractions
{
type psiReactionThermoMoleFractions;
}
or
moleFractions
{
type rhoReactionThermoMoleFractions;
}
depending on the thermodynamics package used in the solver.
Patch provided by Timo Niemi
Resolved bug-report http://www.openfoam.org/mantisbt/view.php?id=1636
This correction corresponds to option 3 of the options proposed by Timo:
Define both ECont and EDisp to be the total emission per surface area,
apply multiplication by 4 in cloudAbsorptionEmission model (the only
place that uses EDisp?). Do not multiply E in P1 at all, divide both
ECont and EDisp in fvDOM.
