The population balance model considers dilatation originating from density
change and mass transfer via source terms describing nucleation as well as
"drift" of the size distribution to smaller or larger sizes. Numerically, the
treatment does not necessarily equal the total dilatation, hence a correction is
introduced to ensure boundedness of the size group fractions.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
and VTT Technical Research Centre of Finland Ltd.
epsilonm is obtained by combining epsilon.gas and epsilon.liquid in a two-phase
system, each of which will apply the epsilonWallFunction at walls; the
epsilonmWallFunction propagates the resulting wall epsilonm into the near-wall
cells.
If the 0/epsilonm file is provided the epsilonmWallFunction should be specified
for walls, if the 0/epsilonm file is not provided it will be generated
automatically and the epsilonmWallFunction applied to walls for which the
epsilonWallFunction is specified in the epsilon.liquid file.
fvMesh::update() now executes at the beginning of the time-step, before time is
incremented and handles topology change, mesh to mesh mapping and redistribution
without point motion. Following each of these mesh changes fields are mapped
from the previous mesh state to new mesh state in a conservative manner. These
mesh changes not occur at most once per time-step.
fvMesh::move() is executed after time is incremented and handles point motion
mesh morphing during the time-step in an Arbitrary Lagrangian Eulerian approach
requiring the mesh motion flux to match the cell volume change. fvMesh::move()
can be called any number of times during the time-step to allow iterative update
of the coupling between the mesh motion and field solution.
This required changing the formulation of the relative velocity in terms of a
scalar velocity coefficient Vc rather than the velocity V0 such that
V0 = Vc*g
where g is the acceleration due to gravity. With MRF rotation
V0 = Vc*(g + <MRF centrifugal acceleration>)
It is not clear for what cases the minVol control is useful or necessary and for
some cases it causes problems with snapping and layer addition if not set to a
sufficiently small value.
There is no clear need for a residualAlpha to be defined specifically for Yi and
read from the fvSolution dictionary, the phase.residualAlpha() should be
suitable to stabilise the Yi equations.
The defaultPatch type currently defaults to empty which is appropriate for 1D
and 2D cases but not when creating the initial blockMesh for snappyHexMesh as
the presence of empty patches triggers the inappropriate application of 2D point
constraint corrections following snapping and morphing. To avoid this hidden
problem a warning is now generated from blockMesh when the defaultPatch is not
explicitly set for cases which generate a default patch, i.e. for which the
boundary is not entirely defined. e.g.
.
.
.
Creating block mesh topology
--> FOAM FATAL IO ERROR:
The 'defaultPatch' type must be specified for the 'defaultFaces' patch, e.g. for snappyHexMesh
defaultPatch
{
name default; // optional
type patch;
}
or for 2D meshes
defaultPatch
{
name frontAndBack; // optional
type empty;
}
.
.
.
All the tutorials have been update to include the defaultPatch specification as
appropriate.
motionSmootherAlgoCheck::checkMesh is used by snappyHexMesh to check the mesh
after snapping and morphing. The minVol test which checks for collapsed cells
is now relative to the cube of the minimum bounding box length so that it is
less dependent on the size of the geometry and less likely to need changing for
very small geometries.
The default value is set in
etc/caseDicts/mesh/generation/meshQualityDict
etc/caseDicts/mesh/generation/meshQualityDict.cfg
//- Minimum cell pyramid volume relative to min bounding box length^3
// Set to a fraction of the smallest cell volume expected.
// Set to very negative number (e.g. -1e30) to disable.
minVol 1e-10;
The unused minArea and minTriangleTwist tests have been removed
to limit the time-step by comparing the film Courant number with the maximum
Courant number obtain from the optional maxCo entry in the system/<film
region>/fvSolution file. If maxCo is not provided the film model does not limit
the time-step.
See tutorials/multiphase/compressibleInterFoam/laminar/cylinder as an example
demonstrating this functionality.
For most multiphase flows it is more appropriate to evaluate the total pressure
from the static pressure obtained from p_rgh rather than from p_rgh directly.
Alpha contact angle boundaries are now specified in the following way
for multiphase solvers (i.e., multiphaseInterFoam,
compressibleMultiphaseInterFoam, and multiphaseEulerFoam):
boundaryField
{
wall
{
type alphaContactAngle;
contactAngleProperties
{
water
{
// Constant contact angle
theta0 90;
}
oil
{
// Dynamic contact angle
theta0 90;
uTheta 1;
thetaA 125;
thetaR 85;
}
}
value uniform 0;
}
}
All solvers now share the same implementation of the alphaContactAngle
boundary condition and the contact angle correction algorithm.
If alpha contact angle boundary conditions are used they must be
specified for all phases or an error will result. The consistency of the
input will also be checked. The angles given for water in the alpha.air
file must be 180 degrees minus the angles given for air in the
alpha.water file.
Updated tutorials for the changes to the blending system. Cases using
"none" blending have been updated to use "continuous" or "segregated" as
appropriate.
The bed tutorial has been extended to include a proper switch to a bed
drag model (AttouFerschneider) when the solid phase displaces the
fluids. This change made the trickleBed case a subset of the bed case,
so the trickleBed has been removed.
These changes are not required for the cases to run with the new
phaseInterface system. The syntax prior to this commit will be read in
the new phaseInterface system's backwards compatibility mode.
The unreliable extrapolateProfile option has been replaced by the more flexible
and reliable profile option which allows the velocity profile to be specified as
a Function1 of the normalised distance to the wall. To simplify the
specification of the most common velocity profiles the new laminarBL (quadratic
profile) and turbulentBL (1/7th power law) Function1s are provided.
In addition to the new profile option the flow rate can now be specified as a
meanVelocity, volumetricFlowRate or massFlowRate, all of which are Function1s of
time.
The following tutorials have been updated to use the laminarBL profile:
multiphase/multiphaseEulerFoam/laminar/titaniaSynthesis
multiphase/multiphaseEulerFoam/laminar/titaniaSynthesisSurface
The following tutorials have been updated to use the turbulentBL profile:
combustion/reactingFoam/Lagrangian/verticalChannel
combustion/reactingFoam/Lagrangian/verticalChannelLTS
combustion/reactingFoam/Lagrangian/verticalChannelSteady
compressible/rhoPimpleFoam/RAS/angledDuct
compressible/rhoPimpleFoam/RAS/angledDuctLTS
compressible/rhoPimpleFoam/RAS/squareBendLiq
compressible/rhoPorousSimpleFoam/angledDuctImplicit
compressible/rhoSimpleFoam/angledDuctExplicitFixedCoeff
compressible/rhoSimpleFoam/squareBend
compressible/rhoSimpleFoam/squareBendLiq
heatTransfer/chtMultiRegionFoam/shellAndTubeHeatExchanger
heatTransfer/chtMultiRegionFoam/shellAndTubeHeatExchanger
incompressible/porousSimpleFoam/angledDuctImplicit
incompressible/porousSimpleFoam/straightDuctImplicit
multiphase/interFoam/RAS/angledDuct
Class
Foam::flowRateInletVelocityFvPatchVectorField
Description
Velocity inlet boundary condition creating a velocity field with
optionally specified profile normal to the patch adjusted to match the
specified mass flow rate, volumetric flow rate or mean velocity.
For a mass-based flux:
- the flow rate should be provided in kg/s
- if \c rho is "none" the flow rate is in m3/s
- otherwise \c rho should correspond to the name of the density field
- if the density field cannot be found in the database, the user must
specify the inlet density using the \c rhoInlet entry
For a volumetric-based flux:
- the flow rate is in m3/s
Usage
\table
Property | Description | Required | Default value
massFlowRate | Mass flow rate [kg/s] | no |
volumetricFlowRate | Volumetric flow rate [m^3/s]| no |
meanVelocity | Mean velocity [m/s]| no |
profile | Velocity profile | no |
rho | Density field name | no | rho
rhoInlet | Inlet density | no |
alpha | Volume fraction field name | no |
\endtable
Example of the boundary condition specification for a volumetric flow rate:
\verbatim
<patchName>
{
type flowRateInletVelocity;
volumetricFlowRate 0.2;
profile laminarBL;
}
\endverbatim
Example of the boundary condition specification for a mass flow rate:
\verbatim
<patchName>
{
type flowRateInletVelocity;
massFlowRate 0.2;
profile turbulentBL;
rho rho;
rhoInlet 1.0;
}
\endverbatim
Example of the boundary condition specification for a volumetric flow rate:
\verbatim
<patchName>
{
type flowRateInletVelocity;
meanVelocity 5;
profile turbulentBL;
}
\endverbatim
The \c volumetricFlowRate, \c massFlowRate or \c meanVelocity entries are
\c Function1 of time, see Foam::Function1s.
The \c profile entry is a \c Function1 of the normalised distance to the
wall. Any suitable Foam::Function1s can be used including
Foam::Function1s::codedFunction1 but Foam::Function1s::laminarBL and
Foam::Function1s::turbulentBL have been created specifically for this
purpose and are likely to be appropriate for most cases.
Note
- \c rhoInlet is required for the case of a mass flow rate, where the
density field is not available at start-up
- The value is positive into the domain (as an inlet)
- May not work correctly for transonic inlets
- Strange behaviour with potentialFoam since the U equation is not solved
See also
Foam::fixedValueFvPatchField
Foam::Function1s::laminarBL
Foam::Function1s::turbulentBL
Foam::Function1s
Foam::flowRateOutletVelocityFvPatchVectorField
This model will generate an error if the diameter is requested. This
will happen if another sub model is included that depends on the
diameter of the continuous phase. It therefore provides a check that the
sub-modelling combination is valid.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
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)
Zoltan only work in parallel so zoltanDecomp can only be used for redistribution
but is much more flexible than ptscotch and provides a range of geometric, graph
and hypergraph methods which can operate in either "partition" or "repartition",
the latter being particularly useful for dynamic load-balancing by migrating
cells between processors rather than creating a completely different
decomposition, thus reducing communication.
Class
Foam::zoltanDecomp
Description
Zoltan redistribution in parallel
Note: Zoltan methods do not support serial operation.
Parameters
- lb_method : The load-balancing algorithm
- block : block partitioning
- random : random partitioning
- rcb : recursive coordinate bisection
- rib : ecursive inertial bisection
- hsfc : Hilbert space-filling curve partitioning
- reftree : refinement tree based partitioning
- graph : choose from collection of methods for graphs
- hypergraph : choose from a collection of methods for hypergraphs
- lb_approach The desired load balancing approach. Only lb_method =
hypergraph or graph uses the lb_approach parameter. Valid values are
- partition : Partition without reference to the current distribution,
recommended for static load balancing.
- repartition : Partition starting from the current data distribution
to keep data migration low, recommended for dynamic load balancing.
- refine : Quickly improve the current data distribution
Default values
- debug_level 0
- imbalance_tol 1.05
- lb_method graph
- lb_approach repartition
Usage
To select the Zoltan graph repartition method add the following entries to
decomposeParDict:
distributor zoltan;
libs ("libzoltanRenumber.so");
The Zoltan lb_method and lb_approach can be changed by adding the
corresponding entries to the optional zoltanCeoffs sub-dictionary, e.g.:
zoltanCoeffs
{
lb_method hypergraph;
lb_approach partition;
}
An example of using Zoltan for redistribution during snappyHexMesh is provided
commented out in
tutorials/incompressible/simpleFoam/motorBike/system/decomposeParDict
and fordynamic load-balancing in
tutorials/multiphase/interFoam/RAS/floatingObject/system/decomposeParDict.
Note that Zoltan must first be compiled in ThirdParty-dev by downloading from
the link in the README file and running Allwmake and then compiling zoltanDecomp
by running Allwmake in src/parallel/decompose.
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.
Basic support is now provided for dynamic mesh redistribution, particularly for
load-balancing. The mesh distributor is selected in the optional 'distributor'
entry in dynamicMeshDict, for example in the
multiphase/interFoam/RAS/floatingObject tutorial case when run in parallel using
the new Allrun-parallel script
distributor
{
type decomposer;
libs ("libfvMeshDistributors.so");
redistributionInterval 10;
}
in which the 'decomposer' form of redistribution is selected to call the mesh
decomposition method specified in decomposeParDict to re-decompose the mesh for
redistribution. The redistributionInterval entry specifies how frequently mesh
redistribution takes place, in the above every 10th time-step. An optional
maxImbalance entry is also provided to control redistribution based on the cell
distribution imbalance:
Class
Foam::fvMeshDistributor::decomposer
Description
Dynamic mesh redistribution using the decomposer
Usage
Example of single field based refinement in all cells:
\verbatim
distributor
{
type decomposer;
libs ("libfvMeshDistributors.so");
// How often to redistribute
redistributionInterval 10;
// Maximum fractional cell distribution imbalance
// before rebalancing
maxImbalance 0.1;
}
\endverbatim
Currently mesh refinement/unrefinement and motion with redistribution is
supported but many aspects of OpenFOAM are not yet and will require further
development, in particular fvModels and Lagrangian.
Also only the geometry-based simple and hierarchical decomposition method are
well behaved for redistribution, scotch and ptScotch cause dramatic changes in
mesh distribution with a corresponding heavy communications overhead limiting
their usefulness or at least the frequency with which they should be called to
redistribute the mesh.
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.
The surfaceVectorField Uf is used instead of the flux field phi for ddtPhiCorr
in moving mesh cases to handle linear and rotating motion and must mapped from
the volVectorField U to new faces created by cell splitting or merging in mesh
refinement/unrefinement.
The floatingObject tutorial has been update to demonstrate this functionality by
adding the following topoChanger entry to dynamicMeshDict:
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)
(ghf none)
);
// Write the refinement level as a volScalarField
dumpLevel true;
}
Note that currently only single rigid body motion is supported (but multi-body
support will be added shortly) and the Crank-Nicolson scheme is not supported.
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.
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"
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.
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.
to the <case>/<time>/uniform or <case>/<processor>/<time>/uniform directory.
Adding a new form of IOdictionary for this purpose allows significant
simplification and rationalisation of regIOobject::writeObject, removing the
need for explicit treatment of different file types.
to provide a single consistent code and user interface to the specification of
physical properties in both single-phase and multi-phase solvers. This redesign
simplifies usage and reduces code duplication in run-time selectable solver
options such as 'functionObjects' and 'fvModels'.
* physicalProperties
Single abstract base-class for all fluid and solid physical property classes.
Physical properties for a single fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties' dictionary.
Physical properties for a phase fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties.<phase>' dictionary.
This replaces the previous inconsistent naming convention of
'transportProperties' for incompressible solvers and
'thermophysicalProperties' for compressible solvers.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the
'physicalProperties' dictionary does not exist.
* phaseProperties
All multi-phase solvers (VoF and Euler-Euler) now read the list of phases and
interfacial models and coefficients from the
'constant/<region>/phaseProperties' dictionary.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the 'phaseProperties'
dictionary does not exist. For incompressible VoF solvers the
'transportProperties' is automatically upgraded to 'phaseProperties' and the
two 'physicalProperties.<phase>' dictionary for the phase properties.
* viscosity
Abstract base-class (interface) for all fluids.
Having a single interface for the viscosity of all types of fluids facilitated
a substantial simplification of the 'momentumTransport' library, avoiding the
need for a layer of templating and providing total consistency between
incompressible/compressible and single-phase/multi-phase laminar, RAS and LES
momentum transport models. This allows the generalised Newtonian viscosity
models to be used in the same form within laminar as well as RAS and LES
momentum transport closures in any solver. Strain-rate dependent viscosity
modelling is particularly useful with low-Reynolds number turbulence closures
for non-Newtonian fluids where the effect of bulk shear near the walls on the
viscosity is a dominant effect. Within this framework it would also be
possible to implement generalised Newtonian models dependent on turbulent as
well as mean strain-rate if suitable model formulations are available.
* visosityModel
Run-time selectable Newtonian viscosity model for incompressible fluids
providing the 'viscosity' interface for 'momentumTransport' models.
Currently a 'constant' Newtonian viscosity model is provided but the structure
supports more complex functions of time, space and fields registered to the
region database.
Strain-rate dependent non-Newtonian viscosity models have been removed from
this level and handled in a more general way within the 'momentumTransport'
library, see section 'viscosity' above.
The 'constant' viscosity model is selected in the 'physicalProperties'
dictionary by
viscosityModel constant;
which is equivalent to the previous entry in the 'transportProperties'
dictionary
transportModel Newtonian;
but backward-compatibility is provided for both the keyword and model
type.
* thermophysicalModels
To avoid propagating the unnecessary constructors from 'dictionary' into the
new 'physicalProperties' abstract base-class this entire structure has been
removed from the 'thermophysicalModels' library. The only use for this
constructor was in 'thermalBaffle' which now reads the 'physicalProperties'
dictionary from the baffle region directory which is far simpler and more
consistent and significantly reduces the amount of constructor code in the
'thermophysicalModels' library.
* compressibleInterFoam
The creation of the 'viscosity' interface for the 'momentumTransport' models
allows the complex 'twoPhaseMixtureThermo' derived from 'rhoThermo' to be
replaced with the much simpler 'compressibleTwoPhaseMixture' derived from the
'viscosity' interface, avoiding the myriad of unused thermodynamic functions
required by 'rhoThermo' to be defined for the mixture.
Same for 'compressibleMultiphaseMixture' in 'compressibleMultiphaseInterFoam'.
This is a significant improvement in code and input consistency, simplifying
maintenance and further development as well as enhancing usability.
Henry G. Weller
CFD Direct Ltd.
