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.
If the mean velocity force is applied to a cyclic patch for parallel
runs include contributions from processorCyclic patches generated
from the decomposition of the cyclic patch
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.
Provides run-time selection of buoyancy sources for compressible solvers
Replaces the built-in buoyancy sources in XiFoam, reactingFoam and
rhoReactingFoam.
e.g. in constant/fvOptions specify
momentumSource
{
type buoyancyForce;
buoyancyForceCoeffs
{
fieldNames (U);
}
}
and optionally specify the buoyancy energy source in the enthalpy
equation:
energySource
{
type buoyancyEnergy;
buoyancyEnergyCoeffs
{
fieldNames (h);
}
}
or internal energy equation
energySource
{
type buoyancyEnergy;
buoyancyEnergyCoeffs
{
fieldNames (e);
}
}
This class does not simply rotate the coordinate system is also changes
it from Cartesian to cylindrical which is not clear from the original name.
We plan to rewrite the coordinateRotation classes to be
coordinateTransformation classes and massively simplify the interface
from the currently unintelligible mess.
by introducing rational base-classes rather than using the hideous
'switch' statement. Further rationalization of the cell-selection
mechanism will be implemented via an appropriate class hierarchy to
replace the remaining 'switch' statement.
Mesh-motion is currently handled very inefficiently for cellSets and not
at all for inter-region coupling. The former will be improved when the
cell-selection classes are written and the latter by making the
meshToMesh class a MeshObject after it has been corrected for mapFields.
fvOptions does not have the appropriate structure to support MRF as it
is based on option selection by user-specified fields whereas MRF MUST
be applied to all velocity fields in the particular solver. A
consequence of the particular design choices in fvOptions made it
difficult to support MRF for multiphase and it is easier to support
frame-related and field related options separately.
Currently the MRF functionality provided supports only rotations but
the structure will be generalized to support other frame motions
including linear acceleration, SRF rotation and 6DoF which will be
run-time selectable.
Example usage:
SBM
{
type tabulatedAccelerationSource;
active true;
selectionMode all;
tabulatedAccelerationSourceCoeffs
{
timeDataFileName "constant/acceleration.dat";
}
}
Where the file constant/acceleration.dat contains a list of tuples
containing time and a vector of the linear acceleration, angular
velocity and angular acceleration e.g.
100
(
(0 ((0 0 0) (0 0 0) (0 0 0)))
(0.001 ((-0.0001 0 4e-05) (5e-5 -0.0002 -3e-8) (0.24 -0.8 -1e-4)))
.
.
.
)
Previous behavior which may be useful for moving-mesh cases can be
selected using the optional entry:
writeTotalArea yes;
The initial total area is written in the log and data file header e.g.:
# Source : faceZone f0
# Faces : 8
# Area : 1.063860e-02
The old separate incompressible and compressible libraries have been removed.
Most of the commonly used RANS and LES models have been upgraded to the
new framework but there are a few missing which will be added over the
next few days, in particular the realizable k-epsilon model. Some of
the less common incompressible RANS models have been introduced into the
new library instantiated for incompressible flow only. If they prove to
be generally useful they can be templated for compressible and
multiphase application.
The Spalart-Allmaras DDES and IDDES models have been thoroughly
debugged, removing serious errors concerning the use of S rather than
Omega.
The compressible instances of the models have been augmented by a simple
backward-compatible eddyDiffusivity model for thermal transport based on
alphat and alphaEff. This will be replaced with a separate run-time
selectable thermal transport model framework in a few weeks.
For simplicity and ease of maintenance and further development the
turbulent transport and wall modeling is based on nut/nuEff rather than
mut/muEff for compressible models so that all forms of turbulence models
can use the same wall-functions and other BCs.
All turbulence model selection made in the constant/turbulenceProperties
dictionary with RAS and LES as sub-dictionaries rather than in separate
files which added huge complexity for multiphase.
All tutorials have been updated so study the changes and update your own
cases by comparison with similar cases provided.
Sorry for the inconvenience in the break in backward-compatibility but
this update to the turbulence modeling is an essential step in the
future of OpenFOAM to allow more models to be added and maintained for a
wider range of cases and physics. Over the next weeks and months more
turbulence models will be added of single and multiphase flow, more
additional sub-models and further development and testing of existing
models. I hope this brings benefits to all OpenFOAM users.
Henry G. Weller
