Now that Cp and Cv are cached it is more convenient and consistent and slightly
more efficient to cache thermal conductivity kappa rather than thermal
diffusivity alpha which is not a fundamental property, the appropriate form
depending on the energy solved for. kappa is converted into the appropriate
thermal diffusivity for the energy form solved for by dividing by the
corresponding cached heat capacity when required, which is efficient.
Following the addition of the new moments functionObject, all related
functionality was removed from sizeDistribution.
In its revised version, sizeDistribution allows for different kinds of
weighted region averaging in case of field-dependent representative
particle properties.
A packaged function has also been added to allow for command line solver
post-processing.
For example, the following function object specification returns the
volume-based number density function:
numberDensity
{
type sizeDistribution;
libs ("libmultiphaseEulerFoamFunctionObjects.so");
writeControl writeTime;
populationBalance bubbles;
functionType numberDensity;
coordinateType volume;
setFormat raw;
}
The same can be achieved using a packaged function:
#includeFunc sizeDistribution
(
populationBalance=bubbles,
functionType=numberDensity,
coordinateType=volume,
funcName=numberDensity
)
Or on the command line:
multiphaseEulerFoam -postProcess -func "
sizeDistribution
(
populationBalance=bubbles,
functionType=numberDensity,
coordinateType=volume,
funcName=numberDensity
)"
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
This function calculates integral (integer moments) or mean properties
(mean, variance, standard deviation) of a size distribution computed with
multiphaseEulerFoam. It has to be run with multiphaseEulerFoam, either
at run-time or with -postProcess. It will not work with the postProcess
utility.
The following function object specification for example returns the first
moment of the volume-based number density function which is equivalent to
the phase fraction of the particulate phase:
moments
{
type moments;
libs ("libmultiphaseEulerFoamFunctionObjects.so");
executeControl timeStep;
writeControl writeTime;
populationBalance bubbles;
momentType integerMoment;
coordinateType volume;
order 1;
}
The same can be achieved using a packaged function:
#includeFunc moments
(
populationBalance=bubbles,
momentType=integerMoment,
coordinateType=volume,
order=1,
funcName=moments
)
Or on the command line:
multiphaseEulerFoam -postProcess -func "
moments
(
populationBalance=bubbles,
momentType=integerMoment,
coordinateType=volume,
order=1,
funcName=moments
)"
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
also adding optional "libs" entry to renumberMeshDict so that the
libzoltanRenumber.so can be loaded at run-time rather than having to recompile
and relink the renumberMesh utility to support it.
There is no longer any need for the surfaceFilmModel abstract base class and
"New" selection method as surface films are now handled within the fvModel
framework. This makes the surfaceFilmModel entry in the surfaceFilmProperties
dictionary redundant.
The surfaceFilm and VoFSurfaceFilm fvModels now instantiate a thermoSingleLayer
providing direct access to all the film functions, simplifying the
implementation better ensuring consistency between the film and primary region
equations.
When snappyHexMesh is run in parallel it re-balances the mesh during refinement
and layer addition by redistribution which requires a decomposition method
that operates in parallel, e.g. hierachical or ptscotch. decomposePar uses a
decomposition method which operates in serial e.g. hierachical but NOT
ptscotch. In order to run decomposePar followed by snappyHexMesh in parallel it
has been necessary to change the method specified in decomposeParDict but now
this is avoided by separately specifying the decomposition and distribution
methods, e.g. in the incompressible/simpleFoam/motorBike case:
numberOfSubdomains 6;
decomposer hierarchical;
distributor ptscotch;
hierarchicalCoeffs
{
n (3 2 1);
order xyz;
}
The distributor entry is also used for run-time mesh redistribution, e.g. in the
multiphase/interFoam/RAS/floatingObject case re-distribution for load-balancing
is enabled in constant/dynamicMeshDict:
distributor
{
type distributor;
libs ("libfvMeshDistributors.so");
redistributionInterval 10;
}
which uses the distributor specified in system/decomposeParDict:
distributor hierarchical;
This rationalisation provides the structure for development of mesh
redistribution and load-balancing.
These models are quite configuration specific. It makes sense to make
them sub-models of the force (drag or lift) models that use them, rather
than making them fundamental properties of the phase system.
This function generates plots of fields averaged over the layers in the
mesh. It is a generalised replacement for the postChannel utility, which
has been removed. An example of this function's usage is as follows:
layerAverage1
{
type layerAverage;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
setFormat raw;
// Patches and/or zones from which layers extrude
patches (bottom);
zones (quarterPlane threeQuartersPlane);
// Spatial component against which to plot
component y;
// Is the geometry symmetric around the centre layer?
symmetric true;
// Fields to average and plot
fields (pMean pPrime2Mean UMean UPrime2Mean k);
}
The code relating to extending refinement to the span of the facet/triangles
intersected by the refinement distance referred to in report
https://bugs.openfoam.org/view.php?id=3361
and temporarily removed may now be selected by the optional
castellatedMeshControls:extendedRefinementSpan entry in snappyHexMeshDict. It
in not clear if this control is generally beneficial and very few users have
reported a preference and too few example cases have been provided to make a
balanced judgement so it has been decided to reinstate the previous default
behaviour and default extendedRefinementSpan to true.
Sampled sets and streamlines now write all their fields to the same
file. This prevents excessive duplication of the geometry and makes
post-processing tasks more convenient.
"axis" entries are now optional in sampled sets and streamlines. When
omitted, a default entry will be used, which is chosen appropriately for
the coordinate set and the write format. Some combinations are not
supported. For example, a scalar ("x", "y", "z" or "distance") axis
cannot be used to write in the vtk format, as vtk requires 3D locations
with which to associate data. Similarly, a point ("xyz") axis cannot be
used with the gnuplot format, as gnuplot needs a single scalar to
associate with the x-axis.
Streamlines can now write out fields of any type, not just scalars and
vectors, and there is no longer a strict requirement for velocity to be
one of the fields.
Streamlines now output to postProcessing/<functionName>/time/<file> in
the same way as other functions. The additional "sets" subdirectory has
been removed.
The raw set writer now aligns columns correctly.
The handling of segments in coordSet and sampledSet has been
fixed/completed. Segments mean that a coordinate set can represent a
number of contiguous lines, disconnected points, or some combination
thereof. This works in parallel; segments remain contiguous across
processor boundaries. Set writers now only need one write method, as the
previous "writeTracks" functionality is now handled by streamlines
providing the writer with the appropriate segment structure.
Coordinate sets and set writers now have a convenient programmatic
interface. To write a graph of A and B against some coordinate X, in
gnuplot format, we can call the following:
setWriter::New("gnuplot")->write
(
directoryName,
graphName,
coordSet(true, "X", X), // <-- "true" indicates a contiguous
"A", // line, "false" would mean
A, // disconnected points
"B",
B
);
This write function is variadic. It supports any number of
field-name-field pairs, and they can be of any primitive type.
Support for Jplot and Xmgrace formats has been removed. Raw, CSV,
Gnuplot, VTK and Ensight formats are all still available.
The old "graph" functionality has been removed from the code, with the
exception of the randomProcesses library and associated applications
(noise, DNSFoam and boxTurb). The intention is that these should also
eventually be converted to use the setWriters. For now, so that it is
clear that the "graph" functionality is not to be used elsewhere, it has
been moved into a subdirectory of the randomProcesses library.
For some systems the thermal coupling between the solid and fluid regions
dominates overall convergence and it may be beneficial to sub-iterate over the
thermal system as the energy solution is cheaper than the pressure-velocity
system. To test this the new optional nEcorr entry in system/fvSolution is
provided which defaults to 1, e.g.
PIMPLE
{
nOuterCorrectors 1;
nEcorr 2;
}
If this proves useful it could be extended and improved by adding convergence
controls.
Note that the solution of the solid regions is now before the fluid regions as
it make more sense if solid regions are sources or sinks of heat to solve them
before the fluid.
This prevents excessive duplication of surface geometry and makes
post-processing tasks in paraview more convenient.
The Nastran and Star-CD surface formats were found not to work, so
support for these output types has been removed. Raw, VTK, Foam and
Ensight formats are all still available.
This improves convergence of some steady-state chtMultiRegionFoam (which uses
the pEqn.H from buoyantPimpleFoam) cases but does not affect transient
simulations unless aggressive pressure relaxation is applied, i.e. transient
SIMPLE.
With the general run-time selectable fvMeshMovers engine compression simulations
can be performed with reactingFoam so there is no longer any need for engine
specific solvers or engineMesh.
An engineFoam script is provided to redirect users to reactingFoam with
instructions.
PDRFoam is a Xi combustion model solver including porosity distributed
resistance and shares code with XiFoam so it is more logical that it should be
in a sub-directory of XiFoam to simplify compilation dependency.
With the general run-time selectable fvMeshMovers engine compression simulations
can be performed with rhoPimpleFoam so there is no longer any need for engine
specific solvers.
A coldEngineFoam script is provided to redirect users to rhoPimpleFoam with
instructions.
With the addition of mesh-motion to XiFoam and the new engine fvMeshMover the
XiEngineFoam kivaTest simple IC engine example now runs in XiFoam and
XiEngineFoam has been removed. This simplifies maintenance provides greater
extensibility.
with the run-time selectable engine userTime embedded in Time.
All parts of the original engineTime relating to the engine geometry have been
moved to engineMesh. This is part of the process of integrating engine
simulations within the standard moving-mesh solvers.
MULES no longer synchronises the limiter field using syncTools. Surface
boundary field synchronisation is now done with a surface-field-specific
communication procedure that should result in scaling benefits relative
to syncTools. This change also means that the limiter does not need to
be continuous face field which is then sliced; it can be a standard
surface field.
Description
Evolves a passive scalar transport equation.
- To specify the field name set the \c field entry
- To employ the same numerical schemes as another field set
the \c schemesField entry,
- The \c diffusivity entry can be set to \c none, \c constant, \c viscosity
- A constant diffusivity is specified with the \c D entry,
- If a momentum transport model is available and the \c viscosity
diffusivety option specified an effective diffusivity may be constructed
from the laminar and turbulent viscosities using the diffusivity
coefficients \c alphal and \c alphat:
\verbatim
D = alphal*nu + alphat*nut
\endverbatim
Example:
\verbatim
#includeFunc scalarTransport(T, alphaD=1, alphaDt=1)
\endverbatim
For incompressible flow the passive scalar may optionally be solved with the
MULES limiter and sub-cycling or semi-implicit in order to maintain
boundedness, particularly if a compressive, PLIC or MPLIC convection
scheme is used.
Example:
\verbatim
#includeFunc scalarTransport(tracer, diffusion=none)
with scheme specification:
div(phi,tracer) Gauss interfaceCompression vanLeer 1;
and solver specification:
tracer
{
nCorr 1;
nSubCycles 3;
MULESCorr no;
nLimiterIter 5;
applyPrevCorr yes;
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-8;
relTol 0;
diffusion
{
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-8;
relTol 0;
}
}
\endverbatim
With this change each functionObject provides the list of fields required so
that the postProcess utility can pre-load them before executing the list of
functionObjects. This provides a more convenient interface than using the
-field or -fields command-line options to postProcess which are now redundant.
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.
