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
To simplify maintenance and further development of chemistry solution the
standardChemistryModel and TDACChemistryModel have been merged into the single
chemistryModel class. Now the TDAC mechanism reduction and tabulation
components can be individually selected or set to "none" or the corresponding
entries in the chemistryProperties dictionary omitted to switch them off thus
reproducing the behaviour of the standardChemistryModel.
For example the following chemistryProperties includes TDAC:
#includeEtc "caseDicts/solvers/chemistry/TDAC/chemistryProperties.cfg"
chemistryType
{
solver ode;
}
chemistry on;
initialChemicalTimeStep 1e-7;
odeCoeffs
{
solver seulex;
absTol 1e-8;
relTol 1e-1;
}
reduction
{
tolerance 1e-4;
}
tabulation
{
tolerance 3e-3;
}
#include "reactionsGRI"
and to run without TDAC the following is sufficient:
chemistryType
{
solver ode;
}
chemistry on;
initialChemicalTimeStep 1e-7;
odeCoeffs
{
solver seulex;
absTol 1e-8;
relTol 1e-1;
}
#include "reactionsGRI"
or the "reduction" and "tabulation" entries can be disabled explicitly:
#includeEtc "caseDicts/solvers/chemistry/TDAC/chemistryProperties.cfg"
chemistryType
{
solver ode;
}
chemistry on;
initialChemicalTimeStep 1e-7;
odeCoeffs
{
solver seulex;
absTol 1e-8;
relTol 1e-1;
}
reduction
{
method none;
tolerance 1e-4;
}
tabulation
{
method none;
tolerance 3e-3;
}
#include "reactionsGRI"
Most tabulation and reduction specific code in TDACChemistryModel has been moved
into the appropriate tabulation and reduction classes and the "none" methods of
each simplified so that they can be instantiated without any user input. This
allows the "none" tabulation and reduction methods to be selected automatically
when the "tabulation" or "reduction" entries are not present in the
chemistryProperties dictionary so that the TDACChemistryModel can be run in the
same manner as the standardChemistryModel when tabulation and reduction are not
required.
This is the first step towards merging TDACChemistryModel with standardChemistryModel.
