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
functionObject to instantiate and execute an fvModel
With this \c functionObject it is possible to use the \c clouds \c fvModel
to track particles without introducing sources into the continuous phase
transport equations, i.e. one-way coupling. When executed from the \c
functions solver module the particles are tracked without evolving the
continuous phase and without drag or other transfer terms there is no
coupling, i.e. a pure Lagrangian simulation.
Example of function object specification:
\verbatim
clouds
{
type fvModel;
executeAtStart false;
fvModel
{
type clouds;
libs ("liblagrangianParcel.so");
}
}
\endverbatim
See also
Foam::functionObject
Foam::functionObjects::fvMeshFunctionObject
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.
The divDevTau matrix now caches the explicit correction flux if fluxRequired is
true for U so that calling flux() on the matrix returns the flux of the complete
stress, not just the implicit part.
Tutorials have been updated to use the new consistent names within the
wall boiling system. The changes are backwards compatible so all
tutorials should run both before and after this change.
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.
This option means that a one field can be mapped to another within the
same patch without specifying the patch name. E.g.:
walls
{
type mappedValue;
//neighbourPatch walls; // <-- Previously required. Still supported.
samePatch yes; // <-- New alternative specification
field T.liquid;
value $internalField;
}
This is useful when the boundary condition is specified using a regular
expression for the patch name.
"wall_.*"
{
type mappedValue;
//neighbourPatch ???; // <-- No unique name can be given
samePatch yes; // <-- Still works
field T.liquid;
value $internalField;
}
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