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.
The "const" transport model now supports the following input where the
thermal condiuctivity is explicitly specified:
transport
{
mu 1.82e-05;
kappa 0.0258;
}
The input in which Prandtl number is specified is also still available:
transport
{
mu 1.82e-05;
Pr 0.71;
}
If both kappa and Pr are specified then an error will be generated.
The energy field limited to limit the temperature is obtained automatically from
the thermo package for the phase except for compressibleInterFoam which uniquely
solves for mixture temperature directly rather than energy. To limit this
temperature rather than the energy the optional 'field' entry should be set to
'T', e.g.:
limitT
{
type limitTemperature;
selectionMode all;
field T;
min 310;
max 500;
}
The temperature equation in compressibleInterFoam is derived from the phase
total internal energy equations including the kinetic energy source terms.
While this formulation handles pressure loss more accurately the kinetic energy
source terms can cause numerical problems and more likely to induce negative
temperatures in regions where the pressure drops rapidly. For such cases it may
be beneficial to solve a temperature equation derived from the phase internal
energy equations, i.e. without the kinetic energy source terms which is now
selectable by setting the optional totalInternalEnergy entry in
constant/phaseProperties to false:
totalInternalEnergy false;
When this entry is omitted the total energy form is used providing
backward-compatibility.
The surfaceInterpolate function object is now a field expression. This
means it works in the same way as mag, grad, etc... It also now has a
packaged configuration and has been included into the postProcessing
test case.
It can be used in the following ways. On the command line:
postProcess -func "surfaceInterpolate(rho, result=rhof)"
rhoPimpleFoam -postProcess -func "surfaceInterpolate(thermo:rho, result=rhof)"
In the controlDict:
functions
{
#includeFunc surfaceInterpolate(rho, result=rhof)
}
By running:
foamGet surfaceInterpolate
Then editing the resulting system/surfaceInterpolate file and then
running postProcess or adding an #includeFunc entry without arguments.
Mesh motion and topology change are now combinable run-time selectable options
within fvMesh, replacing the restrictive dynamicFvMesh which supported only
motion OR topology change.
All solvers which instantiated a dynamicFvMesh now instantiate an fvMesh which
reads the optional constant/dynamicFvMeshDict to construct an fvMeshMover and/or
an fvMeshTopoChanger. These two are specified within the optional mover and
topoChanger sub-dictionaries of dynamicFvMeshDict.
When the fvMesh is updated the fvMeshTopoChanger is first executed which can
change the mesh topology in anyway, adding or removing points as required, for
example for automatic mesh refinement/unrefinement, and all registered fields
are mapped onto the updated mesh. The fvMeshMover is then executed which moved
the points only and calculates the cell volume change and corresponding
mesh-fluxes for conservative moving mesh transport. If multiple topological
changes or movements are required these would be combined into special
fvMeshMovers and fvMeshTopoChangers which handle the processing of a list of
changes, e.g. solidBodyMotionFunctions:multiMotion.
The tutorials/multiphase/interFoam/laminar/sloshingTank3D3DoF case has been
updated to demonstrate this new functionality by combining solid-body motion
with mesh refinement/unrefinement:
/*--------------------------------*- C++ -*----------------------------------*\
========= |
\\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\\ / O peration | Website: https://openfoam.org
\\ / A nd | Version: dev
\\/ M anipulation |
\*---------------------------------------------------------------------------*/
FoamFile
{
format ascii;
class dictionary;
location "constant";
object dynamicMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
mover
{
type motionSolver;
libs ("libfvMeshMovers.so" "libfvMotionSolvers.so");
motionSolver solidBody;
solidBodyMotionFunction SDA;
CofG (0 0 0);
lamda 50;
rollAmax 0.2;
rollAmin 0.1;
heaveA 4;
swayA 2.4;
Q 2;
Tp 14;
Tpn 12;
dTi 0.06;
dTp -0.001;
}
topoChanger
{
type refiner;
libs ("libfvMeshTopoChangers.so");
// How often to refine
refineInterval 1;
// Field to be refinement on
field alpha.water;
// Refine field in between lower..upper
lowerRefineLevel 0.001;
upperRefineLevel 0.999;
// Have slower than 2:1 refinement
nBufferLayers 1;
// Refine cells only up to maxRefinement levels
maxRefinement 1;
// Stop refinement if maxCells reached
maxCells 200000;
// Flux field and corresponding velocity field. Fluxes on changed
// faces get recalculated by interpolating the velocity. Use 'none'
// on surfaceScalarFields that do not need to be reinterpolated.
correctFluxes
(
(phi none)
(nHatf none)
(rhoPhi none)
(alphaPhi.water none)
(meshPhi none)
(meshPhi_0 none)
(ghf none)
);
// Write the refinement level as a volScalarField
dumpLevel true;
}
// ************************************************************************* //
Note that currently this is the only working combination of mesh-motion with
topology change within the new framework and further development is required to
update the set of topology changers so that topology changes with mapping are
separated from the mesh-motion so that they can be combined with any of the
other movements or topology changes in any manner.
All of the solvers and tutorials have been updated to use the new form of
dynamicMeshDict but backward-compatibility was not practical due to the complete
reorganisation of the mesh change structure.
for consistency with the regionToCell topo set source and splitMeshRegions and
provides more logical extension to the multiple and outside point variants insidePoints,
outsidePoint and outsidePoints.
Within the snappyHexMeshDict castellatedMeshControls:
To select the cells outside a surface region:
outsidePoint <point>;
To select the cells outside a number of surface regions:
outsidePoints: (<point> <point>...);
To select the cells within a single surface region:
insidePoint <point>;
To select the cells within a number of surface regions:
insidePoints (<point> <point>...);
If the outside options are specified all cells are initially selected and those
within the surface regions selected by the points are deselected. Subsequently
the cells within the surface regions selected by the inside points are selected.
In order to select to keep the cells in multiple disconnected regions it is
necessary to specify a location in each of those regions as a list of points,
e.g.
castellatedMeshControls
{
.
.
.
locationsInMesh
(
(-0.18 0.003 0.05 )
(-0.09 0.003 0.05)
(0.09 0.003 0.05)
(0.18 0.003 0.05)
);
.
.
.
}
The locationInMesh control is still available for backward compatibility and to
specify a point when meshing a single region.
Description
Mixed boundary condition for temperature, to be used for heat-transfer
on back-to-back baffles. Optional thin thermal layer resistances can be
specified through thicknessLayers and kappaLayers entries.
Specifies gradient and temperature such that the equations are the same
on both sides:
- refGradient = (qs_ + qsNbr)/kappa
- refValue = neighbour value
- mixFraction = nbrKDelta / (nbrKDelta + myKDelta())
where KDelta is heat-transfer coefficient K*deltaCoeffs
and qs is the optional source heat flux.
The thermal conductivity \c kappa can either be retrieved from various
possible sources, as detailed in the class temperatureCoupledBase.
Usage
\table
Property | Description | Required | Default value
Tnbr | name of the field | no | T
thicknessLayers | list of thicknesses per layer [m] | no |
kappaLayers | list of thermal conductivities per layer [W/m/K] | no |
qs | Optional source heat flux [W/m^2] | no | 0
Qs | Optional heat source [W] | no | 0
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type compressible::turbulentTemperatureCoupledBaffleMixed;
Tnbr T;
thicknessLayers (0.1 0.2 0.3 0.4);
kappaLayers (1 2 3 4);
qs uniform 100; // Optional source heat flux [W/m^2]
value uniform 300;
}
\endverbatim
Needs to be on underlying mapped(Wall)FvPatch.
Note that in order to provide an optional heat source either qs or Qs
should be specified, not both.
Description
Transport properties package using non-uniformly-spaced tabulated data for
thermal conductivity vs temperature.
Usage
\table
Property | Description
kappa | Thermal conductivity vs temperature table
\endtable
Example of the specification of the transport properties:
\verbatim
transport
{
kappa
{
values
(
(200 380)
(350 400)
(400 450)
);
}
}
\endverbatim
This required standardisation of the mapping between the class and selection
names of the solid transport models:
constIso -> constIsoSolid
exponential -> exponentialSolid
polynomial -> polynomialSolid
