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.
arguments to the original sourced file. Causes an infinite loop if original source command
is called within a function, e.g.
sourceFile() {
.
}
sourceFile etc/bashrc
The draught rate determines the percentage of affected people by an airflow
caused due to room ventilation or buoyancy effects (cold windows). The draught
rate calculation is valid for room temperatures between 20 and 26 degrees
Celsius and airspeed less than 0.5 m/s. This quantity is used widely for
quantifying offices, auditoriums, or similar rooms in which persons are working.
Patch contributed by Tobias Holzmann
Both AMIMethod and mapNearestMethod are run-time selectable using the standard
OpenFOAM constructor tables, they do not need a separate enumeration-based
selection method which requires duplicate constructors and a lot of other
clutter.
The rotatedBoxToCell topoSet source can now be specified by providing
the geometry of a non-rotated box and how it should be rotated. For
example, in system/topoSetDict:
actions
(
{
name c1;
type cellSet;
action new;
source rotatedBoxToCell;
box (0.4 0.4 -100) (0.6 0.6 100);
centre (0.4 0.4 0);
n1 (1 0 0);
n2 (1 1 0);
}
);
This selects cells in a box rotated from (1 0 0) to (1 1 0) (i.e., 45
degrees around the z-axis), with width and depth of 0.2, height of 200,
and with a bottom left corner at (0.4 0.4 -100).
The origin, i, j, k, specification is still available, and will be used
if the keyword "box" is not present. The equivalent input to the above
in this form is as follows:
actions
(
{
name c1;
type cellSet;
action new;
source rotatedBoxToCell;
origin (0.4 0.4 -100);
i (0.141421 0.141421 0);
j (-0.141421 0.141421 0);
k (0 0 200);
}
);
The mesh in the upstream region of this case has been refined back to
its original density. This restores the wave propagation behaviour
through this region.
Stokes-type waves (i.e., Airy, Stokes2 and Stokes5) now support
specification in terms of wave period, as well as length. The following
specifications are therefore equivalent:
Stokes2
{
length 300; // <-- Wave length specified
amplitude 2.5;
phase 0;
angle 0;
depth 50;
}
Stokes2
{
period 15.643; // <-- Wave period specified
amplitude 2.5;
phase 0;
angle 0;
depth 50;
}
Note that the period is that of the wave in a reference frame with zero
mean flow. Specifying a doppler shifted period is not yet supported.
Exactly one of period or length must be specified. If both, or neither,
are provided then an error will be generated.
Corrections have also been made to the calculation of the celerity of
Stokes2 and Stokes5 waves.
It is now possible to use waveVelocity and waveAlpha boundary conditions
in cases in which the waves generate localised flow reversals along the
boundary. This means waves can be speficied at arbitrary directions and
with zero mean flow. Previously and integral approach, similar to
flowRateOutlet, was used, which was only correct when the direction of
wave propagation was aligned with the boundary normal.
This improvement has been achieved by reformulating the waveVelocity and
waveAlpha boundary conditions in terms of a new fixedValueInletOutlet
boundary condition type. This condition enforces a fixed value in all
cases except that of advection terms in the presence of outflow. In this
configuration a gradient condition is applied that will relax towards
the desired fixed value.
The wavePressure boundary condition has been removed, as it is no longer
necessary or advisable to locally switch between velocity and pressure
formulations along a wave boundary. Wave boundaries should now have the
general fixedFluxPressure or fixedFluxExtrapolatedPressure conditions
applied to the pressure field.
Two new tutorial cases have been created to demonstrate the new
functionality. The multiphase/interFoam/laminar/wave3D case demonstrates
wave generation with zero mean flow and at arbitrary angles to the
boundaries, and incompressible/pimpleFoam/RAS/waveSubSurface
demonstrates usage for sub-surface problems.
