particleFoam has been superseded and replaced by the more general functions
solver module executed by the foamRun application:
foamRun -solver functions
The incompressibleFluid solver specified by either the subSolver or if not
present the solver entry in the controlDict is instantiated to provide the
physical fields needed by fvModel functionObject in which the clouds fvModel is
selected to evolve the Lagrangian particles. See:
tutorials/modules/incompressibleFluid/hopperParticles
tutorials/modules/incompressibleFluid/mixerVessel2DParticles
rhoParticleFoam has been superseded and replaced by the more general functions
solver module executed by the foamRun application:
foamRun -solver functions
The isothermalFluid solver specified by either the subSolver or if not present
the solver entry in the controlDict is instantiated to provide the physical
fields needed by fvModel functionObject in which the clouds fvModel is selected
to evolve the Lagrangian particles.
Description
Solver module to execute the \c functionObjects for a specified solver
The solver specified by either the \c subSolver or if not present the \c
solver entry in the \c controlDict is instantiated to provide the physical
fields needed by the \c functionObjects. The \c functionObjects are then
instantiated from the specifications are read from the \c functions entry in
the \c controlDict and executed in a time-loop also controlled by entries in
\c controlDict and the \c maxDeltaT() returned by the sub-solver.
The fields and other objects registered by the sub-solver are set to
NO_WRITE as they are not changed by the execution of the functionObjects and
should not be written out each write-time. Fields and other objects created
and changed by the execution of the functionObjects are written out.
solvers::functions in conjunction with the scalarTransport functionObject
replaces scalarTransportFoam and provide more general handling of the scalar
diffusivity.
This change means that even if the Courant number is zero, the time step
is adjusted based on maximum time step settings and/or constraints
specified by active fvModels. If none of these additional constraints
are present then adjustment is deactivated.
This change lets the solver be looked up from the region database, so
that aspects of the solution algorithm can be accessed by
functionObjects and fvModels and similar. For example, a fluid solver
could be looked up as follows:
const solvers::fluid& s =
mesh().lookupObject<solvers::fluid>(solver::typeName);
By solving for U and e rather than rhoU and rhoE the convection and stress
matrices can be combined and solved together avoiding the need for Strang
splitting. Conservation of rho*U and rho*E is ensured by constructing and
solving the three equations in sequence, constructing each using the results of
the solution of the previous equations.
Wall boiling properties and state have been named consistently through
the wall boiling boundary conditions and all of its related sub-models.
All changes are backwards compatible. Changes to tutorials will follow
in a separate commit.
A small SuSp stabilisation has been added to the dilation error term to
prevent edge-cases in which the dilation correction exactly cancels out
all implicit transport terms and sources.
This boundary condition now solves for the wall temperature by interval
bisection, which should be significantly more robust than the previous
fixed-point iteration procedure. There is a new non-dimensional
"tolerance" setting that controls how tightly this solution procedure
solves the wall temperature. The "relax" setting is no longer used.
The boundary condition no longer triggers re-evaluation of the
temperature condition in order to re-calculate the heat flux within the
solution iteration. Instead, it extracts physical coefficients from the
form of the boundary condition and uses these to form a linearised
approximation of the heat flux. This is a more general approach, and
will not trigger side-effects associated with re-evaluating the
temperature condition.
The fixedMultiphaseHeatFlux condition has been replaced by a
uniformFixedMultiphaseHeatFlux condition, which constructs a mixed
constraint which portions a specified heat flux between the phases in
such a way as to keep the boundary temperature uniform across all
phases. This can be applied to all phases. It is no longer necessary to
apply a heat flux model to one "master" phase, then map the resulting
temperature to the others. An example specification of this boundary
condition is as follows:
wall
{
type uniformFixedMultiphaseHeatFlux;
q 1000;
relax 0.3;
value $internalField;
}
The wall boiling tutorials have been updated to use these new functions,
and time-varying heat input has been used to replace the
stop-modify-restart pattern present in the single-region cases.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces rhoCentralFoam and all the corresponding
tutorials have been updated and moved to tutorials/modules/shockFluid.
Unlike rhoCentralFoam shockFluid supports mesh refinement/unrefinement, topology
change, run-time mesh-to-mesh mapping, load-balancing in addition to general
mesh-motion.
The tutorials/modules/shockFluid/movingCone case has been updated to demonstrate
run-time mesh-to-mesh mapping mesh topology change based on the
tutorials/modules/incompressibleFluid/movingCone. shockFluid s
Description
Solver module for density-based solution of compressible flow
Based on central-upwind schemes of Kurganov and Tadmor with support for
mesh-motion and topology change.
Reference:
\verbatim
Greenshields, C. J., Weller, H. G., Gasparini, L.,
& Reese, J. M. (2010).
Implementation of semi‐discrete, non‐staggered central schemes
in a colocated, polyhedral, finite volume framework,
for high‐speed viscous flows.
International journal for numerical methods in fluids, 63(1), 1-21.
\endverbatim
SourceFiles
shockFluid.C
See also
Foam::solvers::fluidSolver
Foam::solvers::incompressibleFluid
The fixedDmdt phase change boundary condition has been removed as this
is not a physical model and was only ever needed for testing.
The phase change wall function interface has been simplified and made a
mix-in, rather than a derivation from a fixed value patch field. This
reduces forwarding and mapping code and permits wall functions to derive
from patch fields other than fixed value.
Minor style and consisteny improvements have been made to the wall
boiling wall function.
This change introduces a more physical limiter for the logarithmic
liquid temperature extrapolation employed in the model. It also adds an
operation to turn off extrapolation alltogether for cases with very low
y+ in which the extrapolation behaviour becomes unreliable.
Patch contributed by Juho Peltola, VTT.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces compressibleMultiphaseInterFoam and all the
corresponding tutorials have been updated and moved to
tutorials/modules/compressibleMultiphaseVoF.
compressibleMultiphaseVoF is derived from the multiphaseVoFSolver which adds
compressible multiphase capability to the VoFSolver base-class used as the basis
of all two-phase and multiphase VoF solvers.
Class
Foam::solvers::compressibleMultiphaseVoF
Description
Solver module for the solution of multiple compressible, 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.
A mixture approach for momentum transport is provided in which a single
laminar, RAS or LES model is selected to model the momentum stress.
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
SourceFiles
compressibleMultiphaseVoF.C
See also
Foam::solvers::VoFSolver
Foam::solvers::multiphaseVoFSolver
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces multiphaseInterFoam and all the
corresponding tutorials have been updated and moved to
tutorials/modules/incompressibleMultiphaseVoF.
incompressibleMultiphaseVoF is derived from the multiphaseVoFSolver which adds
multiphase capability to the VoFSolver base-class used as the basis of all
two-phase and multiphase VoF solvers.
Class
Foam::solvers::incompressibleMultiphaseVoF
Description
Solver module for the solution of multiple incompressible, 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.
A mixture approach for momentum transport is provided in which a single
laminar, RAS or LES model is selected to model the momentum stress.
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
SourceFiles
incompressibleMultiphaseVoF.C
See also
Foam::solvers::VoFSolver
Foam::solvers::multiphaseVoFSolver
used in the incompressibleMultiphaseMixture and compressibleMultiphaseMixture
respectively which are used in multiphaseInterFoam and
compressibleMultiphaseInterFoam respectively.
Also the PtrDictionary of phases has been replaced by PtrListDictionary of
phases and iterations over the linked-list replaced by forAll loops which is
easier to use and consistent with the multiphaseEuler solver module.
Much of the VoF functionality, particularly relating to momentum solution, is
independent of the number of phases and it is useful to hold this generic VoF
data and functionality in an abstract base-class and derive twoPhaseVoFSolver
and multiphaseVoFSolver from it, adding two-phase and multiphase functionality
respectively.
The standard Jayatilleke thermal wall function now permits evaluation
via static functions. The boiling wall function now uses these
functions, thereby removing the phase-Jayatilleke base class and
associated duplication of the Jayatilleke model.
It is now possible to map from one field to another within the same
patch, using the mappedValue boundary condition. The restriction is that
the mapping must be from a different field, otherwise field values are
being assigned to themselves, which produces an undefined result.
The mappedValue boundary condition can now be used in place of the
copiedFixedValue condition in the multiphaseEuler module. The
copiedFixedValue condition has therefore been removed.
In addition, the error messages that result from casting a patch to its
mapping engine (mappedPatchBase) have been standardised, and made more
specific to the situation in which the mapping is applied. It may be
inappropriate, for example, to map within the same region or patch.
These cases are now identified and appropriate error messages are
generated.
The error messages have also been made IO errors, so they now provide
context with regards to the dictionary entries that they relate to.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces solidDisplacementFoam and
solidEquilibriumDisplacementFoam and all the corresponding tutorials have been
updated and moved to tutorials/modules/solidDisplacement.
Class
Foam::solvers::solidDisplacement
Description
Solver module for steady or transient segregated finite-volume solution of
linear-elastic, small-strain deformation of a solid body, with optional
thermal diffusion and thermal stresses.
Solves for the displacement vector field D, also generating the stress
tensor field sigma, including the thermal stress contribution if selected.
SourceFiles
solidDisplacement.C
The accelerationFactor option in solidEquilibriumDisplacementFoam is now
available in solidDisplacementFoam when running steady-state, providing a >5x
speed-up to convergence of the updated beamEndLoad case. This makes
solidEquilibriumDisplacementFoam redundant and it has been removed.
so that the same BC can be used for both solidDisplacementFoam and
solidEquilibriumDisplacementFoam. Also updated the beamEndLoad tutorial and
added a solidDisplacementFoam version to test the combined BC.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces XiFoam and all the corresponding
tutorials have been updated and moved to tutorials/modules/XiFluid.
Class
Foam::solvers::XiFluid
Description
Solver module for compressible premixed/partially-premixed combustion with
turbulence modelling.
Combusting RANS code using the b-Xi two-equation model.
Xi may be obtained by either the solution of the Xi transport
equation or from an algebraic expression. Both approaches are
based on Gulder's flame speed correlation which has been shown
to be appropriate by comparison with the results from the
spectral model.
Strain effects are encorporated directly into the Xi equation
but not in the algebraic approximation. Further work need to be
done on this issue, particularly regarding the enhanced removal rate
caused by flame compression. Analysis using results of the spectral
model will be required.
For cases involving very lean Propane flames or other flames which are
very strain-sensitive, a transport equation for the laminar flame
speed is present. This equation is derived using heuristic arguments
involving the strain time scale and the strain-rate at extinction.
the transport velocity is the same as that for the Xi equation.
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, chemical reactions,
combustion, Lagrangian particles, radiation, surface film etc. and
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
XiFluid.C
See also
Foam::solvers::fluidSolver
Foam::solvers::isothermalFluid
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces interFoam and all the corresponding
tutorials have been updated and moved to tutorials/modules/incompressibleVoF.
Both incompressibleVoF and compressibleVoF solver modules are derived from the
common two-phase VoF base-class solvers::VoFSolver which handles the
complexities of VoF interface-compression, boundedness and conservation with
2nd-order schemes in space and time using the semi-implicit MULES limiter and
solution proceedure. This maximises code re-use, improves readability and
simplifies maintenance.
Class
Foam::solvers::incompressibleVoF
Description
Solver module for for 2 incompressible, 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
incompressibleVoF.C
See also
Foam::solvers::VoFSolver
Foam::solvers::compressibleVoF
Tests have shown that the alphaDByAf phase-pressure diffusion coefficient
provides better stability without the optional (1 - phase) prefactor without
introducing excessive smearing of the solution.
In order to ensure temperature consistency between the phases it is necessary to
solve for the mixture temperature rather than the mixture energy or phase
energies which makes it very difficult to conserve energy. The new temperature
equation is a temperature correction on the combined phase energy equations
which will conserve the phase and mixture energies at convergence. The
heat-flux (Laplacian) term is maintained in mixture temperature form so
heat-transfer boundary conditions, in particular for CHT, remain in terms of the
mixture kappaEff. The fvModels are applied to the phase energy equations and
the implicit part converted into an implicit term in the temperature correction
part of the equation to improve convergence and stability.
This development has required some change to the alphaEqn.H and interFoam has
been updated for consistency in preparation for conversion into the
solvers::incompressibleVoF modular module.
All compressibleVoF fvModels and tutorial cases have been updated for the above
change. Note that two entries are now required for the convection terms in the
temperature equation, one for explicit phase energy terms and another for the
implicit phase temperature correction terms, e.g.
tutorials/modules/compressibleVoF/ballValve
div(alphaRhoPhi,e) Gauss limitedLinear 1;
div(alphaRhoPhi,T) Gauss upwind;
In the above the upwind scheme is selected for the phase temperature correction
terms as they are corrections and will converge to a zero contribution. However
there may be cases which converge better if the same scheme is used for both the
energy and temperature terms, more testing is required.
Some momentumTransportModels like the laminar Stokes and generalisedNewtonian
models do no solve transport equations and the transport coefficients they
provide can be predicted at the beginning of the time-step rather than corrected
at the end, after conservative fluxes are available. A particular advantage of
this approach is that complex data cached in the momentumTransportModels
can now be deleted following mesh topology changes and recreated in the
predict() call which is more efficient than attempting to register and map the
data.
Currently the predict() function is only used for the Stokes and
generalisedNewtonian models but it will be extended in the future to cover many
LES models which also do not require the solution of transport equations.
All solvers and solver modules have been update to call the
momentumTransportModel::predict() function at the beginning of the time-step,
controlled by the new PIMPLE transportPredictionFirst control as appropriate.
None of the current thermophysicalTransportModels solve transport equations in
order to evaluate the thermophysical transport properties so it makes more sense
that the evaluation occurs at the beginning of the time-step rather than at the
end where conservative fluxes are available for transport solution. To enable
this the correct() functions have been renamed predict() and called in the
prePredictor() step of foamRun and foamMultiRun and at the beginning of the
time-step in the legacy solvers. A particular advantage of this approach is
that complex data cached in the thermophysicalTransportModels can now be deleted
following mesh topology changes and recreated in the predict() call which is
more efficient than attempting to register and map the data.
An empty correct() function is included in addition to the new predict()
function in thermophysicalTransportModel to support scalar flux transport
closure in the future if needed.
Additionally the two transport model corrector function calls in foamRun and
foamMultiRun have been combined into a single postCorrector() call to allow
greater flexibility in transport property prediction and correction in the
modular solvers.
