Simplifies the setting of the scheme for the phase pressure, e.g. choosing localMax
interpolationSchemes
{
default linear;
pPrime localMax;
}
improves stability and reduces chequerboarding in the solution at higher Courant
numbers.
In order that the phase-fractions sum to 1 it is necessary that the same
diffusivity is used for ALL phases in the implicitPhasePressure option. This is
guaranteed by the new alphaDByAf function which returns a single
surfaceScalarField diffusivity to be used when forming the Laplacian term in the
implicit phase-fraction diffusion correction equation in phaseSystemSolve.
The phase-pressure and turbulent dispersion interface terms are summed over all
phases and interfaces in alphaDByAf to form a single diffusivity.
The timeName() function simply returns the dimensionedScalar::name() which holds
the user-time name of the current time and now that timeName() is no longer
virtual the dimensionedScalar::name() can be called directly. The timeName()
function implementation is maintained for backward-compatibility.
Description
Uniform or non-uniform constant solid thermodynamic properties
Each physical property can specified as either \c uniform in which case the
value entry is read, \c zonal in which case the value entry and zone list
are read or \c file in which case the field file in read from the constant
directory.
Usage
Example of uniform constant solid properties specification:
\verbatim
thermoType constSolidThermo;
rho
{
type uniform;
value 8940;
}
Cv
{
type uniform;
value 385;
}
kappa
{
type uniform;
value 380;
}
\endverbatim
Example of zonal constant solid properties specification where kappa is
different in different zones:
\verbatim
thermoType constSolidThermo;
rho
{
type uniform;
value 8940;
}
Cv
{
type uniform;
value 385;
}
kappa
{
type zonal;
value 380;
zones
{
heater 560;
insulation 100;
}
}
\endverbatim
Example of non-uniform constant solid properties specification:
\verbatim
thermoType constSolidThermo;
rho
{
type file;
}
Cv
{
type file;
}
kappa
{
type file;
}
\endverbatim
where each of the field files are read from the constant directory.
Now fluxes are updated from the mapped fields following mesh topology change
with or without implicit continuity correction enabled by the optional
correctPhi switch.
Given that the number of solid solver modules is currently 1 and unlikely to
exceed 3 it is not very useful to maintain solid and fluid sub-directories and
easier to see the correspondence between the solver modules and tutorial cases
without.
This adds cavitation modelling to the multiphaseEuler solver module as a
phaseTransfer model. The underlying cavitation modelling is the same as
for the compressibleVoF module.
An example specification in constant/phaseProperties is shown below:
phaseTransfer
{
gas_liquid
{
type cavitation;
model Kunz;
liquid water;
pSat 80000;
UInf 5.33;
tInf 0.028142589;
Cc 100;
Cv 100;
}
}
Based on code contributed by Petteri Peltonen, VTT.
The cavitation models used by the compressibleVoF module can now have a
temperature-dependent saturation pressure model specified. For example,
in the constant/fvModels file of a compressibleVoF case:
VoFCavitation
{
type VoFCavitation;
libs ("libcompressibleVoFCavitation.so");
model SchnerrSauer;
liquid water;
// Constant saturation pressure
//pSat 2300;
// Antoine equation for temperature-dependent saturation pressure
pSat
{
type Antoine;
A 22;
B -3000;
C -500;
}
n 1.6e+13;
dNuc 2.0e-06;
Cc 1;
Cv 1;
}
The cavitation models used by the interFoam solver and the
compressibleVoF solver module can now be applied regardless of the
ordering of the liquid and vapour phases. A "liquid" keyword is now
required in the model specification in order to control which phase is
considered to be the condensed liquid state. Previously the liquid phase
was assumed to be the first of the two phases.
The multiphaseEuler module now uses saturation models from the
centralised thermophysical properties library.
The control of these models is slightly different than for the previous
multiphaseEuler-specific saturation models. Where previously a
"saturationPressure" or "saturationTemperature" sub-dictionary was
employed, now "pSat" and "Tsat" entries are used which can be specified
flexibly in a similar manner to function1-s. See the previous commit for
details.
For high-speed flow cases benefiting from extrapolated pressure, e.g. IC engine
piston motion the fixedFluxExtrapolatedPressure pressure BC can now be used with
the transonic pressure solution option.
Class
Foam::coupledMultiphaseTemperatureFvPatchScalarField
Description
Mixed boundary condition for the phase temperature of a phase in an
Euler-Euler multiphase simulation, to be used for heat-transfer with another
region in a CHT case. Optional thin wall material layer resistances can be
specified through thicknessLayers and kappaLayers entries.
See also
Foam::coupledTemperatureFvPatchScalarField
The new tutorial case tutorials/modules/CHT/multiphaseCoolingCylinder2D is a
variant of the coolingCylinder2D case in which a 10% oil droplets in water
mixture flows over and cools a hot cylinder. The case in run with the
foamMultiRun multi-solver executor.
The thermophysical boundary conditions have be moved from the
multiphaseCompressibleMomentumTransportModels library into the new
multiphaseThermophysicalTransportModels library.
Mass transfer rates are now updated following a change in the pressure
if the mass transfer modelling provides a pressure coefficient. This
means that pimple correctors can be used to improve the behaviour of
mass transfer processes that coupled closely to the pressure field.
Simulating the mixing of two miscible liquids is possible my considering
them as different species of a multicomponent fluid. This approach also
supports an arbitrary number of liquids. The twoLiquidMixingFoam solver
has therefore been removed and its tutorials converted to use the
multicomponentFluid solver module.
Bubble waiting time ratio has been made a user adjustable parameter, and
the names of the fields reported by the wallBoilingProperties function
have been rationalised.
Now cases with mesh refinement/unrefinement can be run with the 2nd-order
backward time scheme. However this is for static meshes only, 2nd-order in time
with topology change AND mesh-motion is not currently supported.
This function looks up wall boiling wall functions and collects and
writes out the following data:
- Bubble departure diameter
- Bubble departure frequency
- Nucleation site density
- Effective liquid fraction at the wall
- Quenching heat flux
- Evaporative heat flux
Example of function object specification:
\verbatim
writeWallBoilingProperties
{
type wallBoilingProperties;
functionObjectLibs ( "libmultiphaseEulerFoamFunctionObjects.so" );
writeControl writeTime;
phase liquid;
}
\endverbatim
Patch contributed by Juho Peltola, VTT.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces multiphaseEulerFoam and all the
corresponding tutorials have been updated and moved to
tutorials/modules/multiphaseEuler.
Class
Foam::solvers::multiphaseEuler
Description
Solver module for a system of any number of compressible fluid phases with a
common pressure, but otherwise separate properties. The type of phase model
is run time selectable and can optionally represent multiple species and
in-phase reactions. The phase system is also run time selectable and can
optionally represent different types of momentum, heat and mass transfer.
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
multiphaseEuler.C
See also
Foam::solvers::compressibleVoF
Foam::solvers::fluidSolver
Foam::solvers::incompressibleFluid
alphaEff is now an internal field used only for the implicit energy correction
term, kappaEff, q and divq are the general and rational interface to thermal
transport.
XiFoam and PDRFoam now explicitly instantiate a unityLewisEddyDiffusivity
fluidThermophysicalTransportModel as the the unity Lewis number approximation is
hard-coded into the formulation of the energy/composition system.
Now that thermal transport is implemented as an energy implicit correction on an
explicit temperature gradient formulation it is more efficient if the implicit
correction contains only the implicit terms of the matrix and not the explicit
non-orthogonal or anisotropic correction terms which are cancelled anyway when
the evaluation of the matrix for the current state is subtracted. The new
fvm::laplacianCorrection functions provide a convenient mechanism to efficiently
evaluate only the implicit correction to the laplacian and is now used in all
the thermophysicalTransportModels.
The thermodynamic density field is now named "rho" by default and only renamed
"thermo:rho" by solvers that create and maintain a separate continuity density
field which is named "rho". This change significantly simplifies and
standardises the specification of schemes and boundary conditions requiring
density as it is now always named "rho" or "rho.<phase>" unless under some very
unusual circumstances the thermodynamic rather than continuity density is
required for a solver maintaining both.
The advantage of this change is particularly noticeable for multiphase
simulations in which each phase has its own density now named "rho.<phase>"
rather than "thermo:rho.<phase>" as separate phase continuity density fields are
not required so for multiphaseEulerFoam the scheme specification:
"div\(alphaRhoPhi.*,\(p\|thermo:rho.*\)\)" Gauss limitedLinear 1;
is now written:
"div\(alphaRhoPhi.*,\(p\|rho.*\)\)" Gauss limitedLinear 1;
The basic thermophysical properties are now considered fundamental and complex
models like kineticTheoryModel using these names for some other purpose must
disambiguate using typedName to prepend the model name to the field name.
This change standardises, rationalises and simplifies the specification of
fvSchemes and boundary conditions.
thermo:rho will also be renamed rho in a subsequent commit to complete this
rationalisation.
