so that it can now be used with either the isothermalFluid or fluid solver
modules, thus supporting non-uniform fluid properties, compressibility and
thermal effect. This development makes the special potentialFreeSurfaceFoam
solver redundant as both the isothermalFluid and fluid solver modules are more
general and has been removed and replaced with a user redirection script.
The tutorials/multiphase/potentialFreeSurfaceFoam cases have been updated to run
with the isothermalFluid solver module:
tutorials/multiphase/potentialFreeSurfaceFoam/oscillatingBox
tutorials/multiphase/potentialFreeSurfaceFoam/movingOscillatingBox
which demonstrate how to upgrade potentialFreeSurfaceFoam cases to
isothermalFluid.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces compressibleInterFoam and all the
corresponding tutorials have been updated and moved to
tutorials/modules/compressibleVoF.
Class
Foam::solvers::compressibleVoF
Description
Solver module for for 2 compressible, non-isothermal immiscible fluids
using a VOF (volume of fluid) phase-fraction based interface capturing
approach, with optional mesh motion and mesh topology changes including
adaptive re-meshing.
The momentum and other fluid properties are of the "mixture" and a single
momentum equation is solved.
Either mixture or two-phase transport modelling may be selected. In the
mixture approach a single laminar, RAS or LES model is selected to model the
momentum stress. In the Euler-Euler two-phase approach separate laminar,
RAS or LES selected models are selected for each of the phases.
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
Optional fvModels and fvConstraints are provided to enhance the simulation
in many ways including adding various sources, Lagrangian
particles, surface film etc. and constraining or limiting the solution.
SourceFiles
compressibleVoF.C
See also
Foam::solvers::fluidSolver
MRF (multiple reference frames) can now be used to simulate SRF (single
reference frame) cases by defining the MRF zone to include all the cells is the
mesh and applying appropriate boundary conditions. The huge advantage of this
is that MRF can easily be added to any solver by the addition of forcing terms
in the momentum equation and absolute velocity to relative flux conversions in
the formulation of the pressure equation rather than having to reformulate the
momentum and pressure system based on the relative velocity as in traditional
SRF. Also most of the OpenFOAM solver applications and all the solver modules
already support MRF.
To enable this generalisation of MRF the transformations necessary on the
velocity boundary conditions in the MRF zone can no longer be handled by the
MRFZone class itself but special adapted fvPatchFields are required. Although
this adds to the case setup it provides much greater flexibility and now complex
inlet/outlet conditions can be applied within the MRF zone, necessary for some
SRF case and which was not possible in the original MRF implementation. Now for
walls rotating within the MRF zone the new 'MRFnoSlip' velocity boundary
conditions must be applied, e.g. in the
tutorials/modules/incompressibleFluid/mixerVessel2DMRF/constant/MRFProperties
case:
boundaryField
{
rotor
{
type MRFnoSlip;
}
stator
{
type noSlip;
}
front
{
type empty;
}
back
{
type empty;
}
}
similarly for SRF cases, e.g. in the
tutorials/modules/incompressibleFluid/mixerSRF case:
boundaryField
{
inlet
{
type fixedValue;
value uniform (0 0 -10);
}
outlet
{
type pressureInletOutletVelocity;
value $internalField;
}
rotor
{
type MRFnoSlip;
}
outerWall
{
type noSlip;
}
cyclic_half0
{
type cyclic;
}
cyclic_half1
{
type cyclic;
}
}
For SRF case all the cells should be selected in the MRFproperties dictionary
which is achieved by simply setting the optional 'selectionMode' entry to all,
e.g.:
SRF
{
selectionMode all;
origin (0 0 0);
axis (0 0 1);
rpm 1000;
}
In the above the rotational speed is set in RPM rather than rad/s simply by
setting the 'rpm' entry rather than 'omega'.
The tutorials/modules/incompressibleFluid/rotor2DSRF case is more complex and
demonstrates a transient SRF simulation of a rotor requiring the free-stream
velocity to rotate around the apparently stationary rotor which is achieved
using the new 'MRFFreestreamVelocity' velocity boundary condition. The
equivalent simulation can be achieved by simply rotating the entire mesh and
keeping the free-stream flow stationary and this is demonstrated in the
tutorials/modules/incompressibleFluid/rotor2DRotating case for comparison.
The special SRFSimpleFoam and SRFPimpleFoam solvers are now redundant and have
been replaced by redirection scripts providing details of the case migration
process.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces pimpleFoam, pisoFoam and simpleFoam and all
the corresponding tutorials have been updated and moved to
tutorials/modules/incompressibleFluid.
Class
Foam::solvers::incompressibleFluid
Description
Solver module for steady or transient turbulent flow of incompressible
isothermal fluids with optional mesh motion and change.
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
Optional fvModels and fvConstraints are provided to enhance the simulation
in many ways including adding various sources, constraining or limiting
the solution.
Reference:
\verbatim
Greenshields, C. J., & Weller, H. G. (2022).
Notes on Computational Fluid Dynamics: General Principles.
CFD Direct Ltd.: Reading, UK.
\endverbatim
SourceFiles
incompressibleFluid.C
See also
Foam::solvers::fluidSolver
Foam::solvers::isothermalFluid
in which different solver modules can be selected in each region to for complex
conjugate heat-transfer and other combined physics problems such as FSI
(fluid-structure interaction).
For single-region simulations the solver module is selected, instantiated and
executed in the PIMPLE loop in the new foamRun application.
For multi-region simulations the set of solver modules, one for each region, are
selected, instantiated and executed in the multi-region PIMPLE loop of new the
foamMultiRun application.
This provides a very general, flexible and extensible framework for complex
coupled problems by creating more solver modules, either by converting existing
solver applications or creating new ones.
The current set of solver modules provided are:
isothermalFluid
Solver module for steady or transient turbulent flow of compressible
isothermal fluids with optional mesh motion and mesh topology changes.
Created from the rhoSimpleFoam, rhoPimpleFoam and buoyantFoam solvers but
without the energy equation, hence isothermal. The buoyant pressure
formulation corresponding to the buoyantFoam solver is selected
automatically by the presence of the p_rgh pressure field in the start-time
directory.
fluid
Solver module for steady or transient turbulent flow of compressible fluids
with heat-transfer for HVAC and similar applications, with optional
mesh motion and mesh topology changes.
Derived from the isothermalFluid solver module with the addition of the
energy equation from the rhoSimpleFoam, rhoPimpleFoam and buoyantFoam
solvers, thus providing the equivalent functionality of these three solvers.
multicomponentFluid
Solver module for steady or transient turbulent flow of compressible
reacting fluids with optional mesh motion and mesh topology changes.
Derived from the isothermalFluid solver module with the addition of
multicomponent thermophysical properties energy and specie mass-fraction
equations from the reactingFoam solver, thus providing the equivalent
functionality in reactingFoam and buoyantReactingFoam. Chemical reactions
and/or combustion modelling may be optionally selected to simulate reacting
systems including fires, explosions etc.
solid
Solver module for turbulent flow of compressible fluids for conjugate heat
transfer, HVAC and similar applications, with optional mesh motion and mesh
topology changes.
The solid solver module may be selected in solid regions of a CHT case, with
either the fluid or multicomponentFluid solver module in the fluid regions
and executed with foamMultiRun to provide functionality equivalent
chtMultiRegionFoam but in a flexible and extensible framework for future
extension to more complex coupled problems.
All the usual fvModels, fvConstraints, functionObjects etc. are available with
these solver modules to support simulations including body-forces, local sources,
Lagrangian clouds, liquid films etc. etc.
Converting compressibleInterFoam and multiphaseEulerFoam into solver modules
would provide a significant enhancement to the CHT capability and incompressible
solvers like pimpleFoam run in conjunction with solidDisplacementFoam in
foamMultiRun would be useful for a range of FSI problems. Many other
combinations of existing solvers converted into solver modules could prove
useful for a very wide range of complex combined physics simulations.
All tutorials from the rhoSimpleFoam, rhoPimpleFoam, buoyantFoam, reactingFoam,
buoyantReactingFoam and chtMultiRegionFoam solver applications replaced by
solver modules have been updated and moved into the tutorials/modules directory:
modules
├── CHT
│ ├── coolingCylinder2D
│ ├── coolingSphere
│ ├── heatedDuct
│ ├── heatExchanger
│ ├── reverseBurner
│ └── shellAndTubeHeatExchanger
├── fluid
│ ├── aerofoilNACA0012
│ ├── aerofoilNACA0012Steady
│ ├── angledDuct
│ ├── angledDuctExplicitFixedCoeff
│ ├── angledDuctLTS
│ ├── annularThermalMixer
│ ├── BernardCells
│ ├── blockedChannel
│ ├── buoyantCavity
│ ├── cavity
│ ├── circuitBoardCooling
│ ├── decompressionTank
│ ├── externalCoupledCavity
│ ├── forwardStep
│ ├── helmholtzResonance
│ ├── hotRadiationRoom
│ ├── hotRadiationRoomFvDOM
│ ├── hotRoom
│ ├── hotRoomBoussinesq
│ ├── hotRoomBoussinesqSteady
│ ├── hotRoomComfort
│ ├── iglooWithFridges
│ ├── mixerVessel2DMRF
│ ├── nacaAirfoil
│ ├── pitzDaily
│ ├── prism
│ ├── shockTube
│ ├── squareBend
│ ├── squareBendLiq
│ └── squareBendLiqSteady
└── multicomponentFluid
├── aachenBomb
├── counterFlowFlame2D
├── counterFlowFlame2D_GRI
├── counterFlowFlame2D_GRI_TDAC
├── counterFlowFlame2DLTS
├── counterFlowFlame2DLTS_GRI_TDAC
├── cylinder
├── DLR_A_LTS
├── filter
├── hotBoxes
├── membrane
├── parcelInBox
├── rivuletPanel
├── SandiaD_LTS
├── simplifiedSiwek
├── smallPoolFire2D
├── smallPoolFire3D
├── splashPanel
├── verticalChannel
├── verticalChannelLTS
└── verticalChannelSteady
Also redirection scripts are provided for the replaced solvers which call
foamRun -solver <solver module name> or foamMultiRun in the case of
chtMultiRegionFoam for backward-compatibility.
Documentation for foamRun and foamMultiRun:
Application
foamRun
Description
Loads and executes an OpenFOAM solver module either specified by the
optional \c solver entry in the \c controlDict or as a command-line
argument.
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
Usage
\b foamRun [OPTION]
- \par -solver <name>
Solver name
- \par -libs '(\"lib1.so\" ... \"libN.so\")'
Specify the additional libraries loaded
Example usage:
- To run a \c rhoPimpleFoam case by specifying the solver on the
command line:
\verbatim
foamRun -solver fluid
\endverbatim
- To update and run a \c rhoPimpleFoam case add the following entries to
the controlDict:
\verbatim
application foamRun;
solver fluid;
\endverbatim
then execute \c foamRun
Application
foamMultiRun
Description
Loads and executes an OpenFOAM solver modules for each region of a
multiregion simulation e.g. for conjugate heat transfer.
The region solvers are specified in the \c regionSolvers dictionary entry in
\c controlDict, containing a list of pairs of region and solver names,
e.g. for a two region case with one fluid region named
liquid and one solid region named tubeWall:
\verbatim
regionSolvers
{
liquid fluid;
tubeWall solid;
}
\endverbatim
The \c regionSolvers entry is a dictionary to support name substitutions to
simplify the specification of a single solver type for a set of
regions, e.g.
\verbatim
fluidSolver fluid;
solidSolver solid;
regionSolvers
{
tube1 $fluidSolver;
tubeWall1 solid;
tube2 $fluidSolver;
tubeWall2 solid;
tube3 $fluidSolver;
tubeWall3 solid;
}
\endverbatim
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
Usage
\b foamMultiRun [OPTION]
- \par -libs '(\"lib1.so\" ... \"libN.so\")'
Specify the additional libraries loaded
Example usage:
- To update and run a \c chtMultiRegion case add the following entries to
the controlDict:
\verbatim
application foamMultiRun;
regionSolvers
{
fluid fluid;
solid solid;
}
\endverbatim
then execute \c foamMultiRun
The cellProc field is the field of cell-processor labels.
The names "distribution" and "dist" have been removed as these are
ambiguous in relation to other forms of distribution and to distance.
The reconstructPar utility now reconstructs the mesh if and when it is
necessary to do so. The reconstructParMesh utility is therefore no
longer necessary and has been removed.
It was necessary/advantagous to consolidate these utilities into one
because in the case of mesh changes it becomes increasingly less clear
which of the separate utilities is responsible for reconstructing data
that is neither clearly physical field nor mesh topology; e.g., moving
points, sets, refinement data, and so on.
and moveDynamicMesh renamed to moveMesh
Description
Mesh motion and topological mesh change utility.
Executes the mover, topoChanger and distributor specified in the
dynamicMeshDict in a time-loop.
When cloning a case, users can copy the field data from the
from the latest time directory in the source case, using
the -latestTime option.
The -startFrom option enables the copied time directory to be
renamed, often as the '0' (zero) directory in the new case, e.g.
foamCloneCase -latestTime -startFrom 0 sourceCase newCase
When the time directories in the source and new cases are
different, the uniform directory and flux field "phi" are
deleted from the copied time directory to avoid incorrect
initial state.
Solver for steady or transient buoyant, turbulent flow of compressible fluids
for ventilation and heat-transfer, with optional mesh motion and mesh topology
changes. Created by merging buoyantSimpleFoam and buoyantPimpleFoam to provide
a more general solver and simplify maintenance.
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.
topoSet is a more flexible and extensible replacement for setSet using standard
OpenFOAM dictionary input format rather than the limited command-line input
format developed specifically for setSet. This replacement allows for the
removal of a significant amount of code simplifying maintenance and the addition
of more topoSet sources.
The generation script has also been modified slightly to prevent empty
entries being generated for scripts with no options; e.g., the scripts
in $WM_PROJECT_DIR/bin that report a change in application name
The fireFoam solver has solver has been replaced by the more general
buoyantReactingFoam solver, which supports buoyant compressible reacting flow
coupled to multiple run-time-selectable lagrangian clouds and surface film
modelling and optional hydrostatic initialisation of the pressure and p_rgh.
Hydrostatic initialisation of the pressure fields is useful for large fires in
open domains where the stability of the initial flow is dominated by the initial
pressure distribution in the domain and at the boundaries. The optional
hydrostaticInitialization switch in fvSolution/PIMPLE with
nHydrostaticCorrectors enables hydrostatic initialisation, e.g.
PIMPLE
{
momentumPredictor yes;
nOuterCorrectors 1;
nCorrectors 2;
nNonOrthogonalCorrectors 0;
hydrostaticInitialization yes;
nHydrostaticCorrectors 5;
}
and the resulting ph_rgh field can be used with the prghTotalHydrostaticPressure
p_rgh boundary condition to apply this hydrostatic pressure distribution at the
boundaries throughout the simulation.
See the following cases for examples transferred from fireFoam:
$FOAM_TUTORIALS/combustion/buoyantReactingFoam/RAS
With the new fvModels framework it is now possible to implement complex models
and wrappers around existing complex models which can then be optionally
selected in any general solver which provides compatible fields and
thermophysical properties. This simplifies code development and maintenance by
significantly reducing complex code duplication and also provide the opportunity
of running these models in other solvers without the need for code duplication
and alteration.
The immediate advantage of this development is the replacement of the
specialised Lagrangian solvers with their general counterparts:
reactingParticleFoam -> reactingFoam
reactingParcelFoam -> reactingFoam
sprayFoam -> reactingFoam
simpleReactingParticleFoam -> reactingFoam
buoyantReactingParticleFoam -> buoyantReactingFoam
For example to run a reactingParticleFoam case in reactingFoam add the following
entries in constant/fvModels:
buoyancyForce
{
type buoyancyForce;
}
clouds
{
type clouds;
libs ("liblagrangianParcel.so");
}
which add the acceleration due to gravity needed by Lagrangian clouds and the
clouds themselves.
See the following cases for examples converted from reactingParticleFoam:
$FOAM_TUTORIALS/combustion/reactingFoam/Lagrangian
and to run a buoyantReactingParticleFoam case in buoyantReactingFoam add the
following entry constant/fvModels:
clouds
{
type clouds;
libs ("liblagrangianParcel.so");
}
to add support for Lagrangian clouds and/or
surfaceFilm
{
type surfaceFilm;
libs ("libsurfaceFilmModels.so");
}
to add support for surface film. The buoyancyForce fvModel is not required in
this case as the buoyantReactingFoam solver has built-in support for buoyancy
utilising the p_rgh formulation to provide better numerical handling for this
force for strongly buoyancy-driven flows.
See the following cases for examples converted from buoyantReactingParticleFoam:
$FOAM_TUTORIALS/combustion/buoyantReactingFoam/Lagrangian
All the tutorial cases for the redundant solvers have been updated and converted
into their new equivalents and redirection scripts replace these solvers to
provide users with prompts on which solvers have been replaced by which and
information on how to upgrade their cases.
To support this change and allow all previous Lagrangian tutorials to run as
before the special Lagrangian solver fvSolution/PIMPLE control
solvePrimaryRegion has been replaced by the more general and useful controls:
models : Enable the fvModels
thermophysics : Enable thermophysics (energy and optional composition)
flow : Enable flow (pressure/velocity system)
which also replace the fvSolution/PIMPLE control frozenFlow present in some
solvers. These three controls can be used in various combinations to allow for
example only the fvModels to be evaluated, e.g. in
$FOAM_TUTORIALS/combustion/buoyantReactingFoam/Lagrangian/rivuletPanel
PIMPLE
{
models yes;
thermophysics no;
flow no;
.
.
.
so that only the film is solved. Or during the start-up of a case it might be
beneficial to run the pressure-velocity system for a while without updating
temperature which can be achieved by switching-off thermophysics. Also the
behaviour of the previous frozenFlow switch can be reproduced by switching flow
off with the other two switches on, allowing for example reactions, temperature
and composition update without flow.
This makes usage of transformPoints the same as for
surfaceTransformPoints. Transformations are supplied as a string and are
applied in sequence.
Usage
transformPoints "\<transformations\>" [OPTION]
Supported transformations:
- "translate=<translation vector>"
Translational transformation by given vector
- "rotate=(<n1 vector> <n2 vector>)"
Rotational transformation from unit vector n1 to n2
- "Rx=<angle [deg] about x-axis>"
Rotational transformation by given angle about x-axis
- "Ry=<angle [deg] about y-axis>"
Rotational transformation by given angle about y-axis
- "Rz=<angle [deg] about z-axis>"
Rotational transformation by given angle about z-axis
- "Ra=<axis vector> <angle [deg] about axis>"
Rotational transformation by given angle about given axis
- "scale=<x-y-z scaling vector>"
Anisotropic scaling by the given vector in the x, y, z
coordinate directions
Example usage:
transformPoints \
"translate=(-0.05 -0.05 0), \
Rz=45, \
translate=(0.05 0.05 0)"
The new fvModels is a general interface to optional physical models in the
finite volume framework, providing sources to the governing conservation
equations, thus ensuring consistency and conservation. This structure is used
not only for simple sources and forces but also provides a general run-time
selection interface for more complex models such as radiation and film, in the
future this will be extended to Lagrangian, reaction, combustion etc. For such
complex models the 'correct()' function is provided to update the state of these
models at the beginning of the PIMPLE loop.
fvModels are specified in the optional constant/fvModels dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The new fvConstraints is a general interface to optional numerical constraints
applied to the matrices of the governing equations after construction and/or to
the resulting field after solution. This system allows arbitrary changes to
either the matrix or solution to ensure numerical or other constraints and hence
violates consistency with the governing equations and conservation but it often
useful to ensure numerical stability, particularly during the initial start-up
period of a run. Complex manipulations can be achieved with fvConstraints, for
example 'meanVelocityForce' used to maintain a specified mean velocity in a
cyclic channel by manipulating the momentum matrix and the velocity solution.
fvConstraints are specified in the optional system/fvConstraints dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The separation of fvOptions into fvModels and fvConstraints provides a rational
and consistent separation between physical and numerical models which is easier
to understand and reason about, avoids the confusing issue of location of the
controlling dictionary file, improves maintainability and easier to extend to
handle current and future requirements for optional complex physical models and
numerical constraints.
The phase-change functionality in interPhaseChangeFoam has been generalised and
moved into the run-time selectable twoPhaseChange library included into
interFoam providing optional phase-change. The three cavitation models provided
in interPhaseChangeFoam are now included in the twoPhaseChange library and the
two interPhaseChangeFoam cavitation tutorials updated for interFoam.
interPhaseChangeFoam has been replaced by a user redirection script which prints
the following message:
The interPhaseChangeFoam solver has solver has been replaced by the more general
interFoam solver, which now supports phase-change using the new twoPhaseChange
models library.
To run with with phase-change create a constant/phaseChangeProperties dictionary
containing the phase-change model specification, e.g.
phaseChangeModel SchnerrSauer;
pSat 2300; // Saturation pressure
See the following cases for an example converted from interPhaseChangeFoam:
$FOAM_TUTORIALS/multiphase/interFoam/laminar/cavitatingBullet
$FOAM_TUTORIALS/multiphase/interFoam/RAS/propeller
There is now only one -listSwitches argument available to the
applications; -listUnsetSwitches and -listRegisteredSwitches have been
removed. -listSwitches prints everything, now also including the values.
It also categorises the output based on whether the switch has a
default, if it has the same value as that default, and whether or not it
is registered with a re-reader.
The list of debug switches in etc/controlDict has been reduced to only
the switches which have non-zero values. In general the list of valid
switches varies per application and per library, so it is not possible
to keep a single definitive list of all switches. The -listSwitches
argument provides the definitive list on a per applicaton basis.
Setting of defaults for named enum optimisation switches has been added.
The reactingtTwoPhaseEulerFoam solver has been replaced by the more general
multiphaseEulerFoam solver which supports two-phase and multiphase systems
containing fluid and stationary phases, compressible or incompressible, with
heat and mass transfer, reactions, size distribution and all the usual phase
interaction and transfer models.
All reactingtTwoPhaseEulerFoam tutorials have been ported to multiphaseEulerFoam
to demonstrate two-phase capability with a wide range of phase and
phase-interaction models.
When running with two-phases the optional referencePhase entry in
phaseProperties can be used to specify which phase fraction should not be
solved, providing compatibility with reactingtTwoPhaseEulerFoam, see
tutorials/multiphase/multiphaseEulerFoam/RAS/fluidisedBed
tutorials/multiphase/multiphaseEulerFoam/laminar/bubbleColumn
for examples.
The new multiphaseEulerFoam is based on reactingMultiphaseEulerFoam with some
improvements and rationalisation to assist maintenance and further development.
The phase system solution has been enhanced to handle two phases more
effectively and all two-phase specific models updated for compatibility so that
multiphaseEulerFoam can also replace reactingTwoPhaseEulerFoam.
When running multiphaseEulerFoam with only two-phases the default behaviour is
to solve for both phase-fractions but optionally a reference phase can be
specified so that only the other phase-fraction is solved, providing better
compatibility with the behaviour of reactingTwoPhaseEulerFoam.
All reactingMultiphaseEulerFoam and reactingTwoPhaseEulerFoam tutorials have
been updated for multiphaseEulerFoam.
providing the shear-stress term in the momentum equation for incompressible and
compressible Newtonian, non-Newtonian and visco-elastic laminar flow as well as
Reynolds averaged and large-eddy simulation of turbulent flow.
The general deviatoric shear-stress term provided by the MomentumTransportModels
library is named divDevTau for compressible flow and divDevSigma (sigma =
tau/rho) for incompressible flow, the spherical part of the shear-stress is
assumed to be either included in the pressure or handled separately. The
corresponding stress function sigma is also provided which in the case of
Reynolds stress closure returns the effective Reynolds stress (including the
laminar contribution) or for other Reynolds averaged or large-eddy turbulence
closures returns the modelled Reynolds stress or sub-grid stress respectively.
For visco-elastic flow the sigma function returns the effective total stress
including the visco-elastic and Newtonian contributions.
For thermal flow the heat-flux generated by thermal diffusion is now handled by
the separate ThermophysicalTransportModels library allowing independent run-time
selection of the heat-flux model.
During the development of the MomentumTransportModels library significant effort
has been put into rationalising the components and supporting libraries,
removing redundant code, updating names to provide a more logical, consistent
and extensible interface and aid further development and maintenance. All
solvers and tutorials have been updated correspondingly and backward
compatibility of the input dictionaries provided.
Henry G. Weller
CFD Direct Ltd.
With the selection of the Boussinesq equation of state the general buoyancy
solvers buoyantSimpleFoam and buoyantPimpleFoam can be used instead of the
specialised Boussinesq solvers avoiding the need for special implementation of
thermal and pressure boundary conditions and providing support for radiation and
fvOptions which would not have been feasible or practical in the Boussinesq
solvers.
Other incompressible equations of state are also supported; for most gaseous
problems the incompressiblePerfectGas equation of state is likely to be more
accurate than the Boussinesq equation of state.
The buoyantBoussinesq[SP]impleFoam tutorials have been updated and moved to the
corresponding buoyant[SP]impleFoam directories.
for consistency with WM_PROJECT. Now "etc" files are assumed to be in etc
sub-directories of WM_PROJECT_SITE and WM_PROJECT_INST_DIR allowing other files
to be stored in those directories. The search order is now:
Search for files from user/group/shipped directories.
The search scheme allows for version-specific and
version-independent files using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/
- ~/.OpenFOAM/
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/etc/
- $WM_PROJECT_SITE/etc/
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/etc/
- $WM_PROJECT_INST_DIR/site/etc/
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/
\return The list of full paths of all the matching files or
an empty list if the name cannot be found.
Optionally abort if the file cannot be found.
Optionally stop search after the first file has been found.
This change was proposed and agreed by the sponsors of the OpenFOAM project on
the OpenFOAM Hub, see https://openfoam.org/maintenance/
The sonicFoam, sonicDyMFoam and sonicLiquidFoam functionality has been merged
into the transonic option of the latest rhoPimpleFoam solver and the
corresponding tutorials moved into the rhoPimpleFoam tutorials directory.
To run rhoPimpleFoam in transonic mode set the transonic option in the
PIMPLE sub-dictionary of fvSolution:
PIMPLE
{
.
.
.
transonic yes;
}
