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.
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.
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
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 new fluidThermophysicalTransportModel and solidThermophysicalTransportModel
are derived from thermophysicalTransportModel providing a consistent and unified
interface for heat transport within and between regions. Coupled and external
heat-transfer boundary conditions can now be written independent of the
thermophysical properties or transport modelling of the regions providing
greater flexibility, simpler code and reduces the maintenance overhead.
The previous fluidThermophysicalTransportModel typedef has been renamed
fluidThermoThermophysicalTransportModel as it is instantiated on fluidThermo,
freeing the name fluidThermophysicalTransportModel for the new base-class.
The surfaceFilm fvModel has been renamed surfaceFilms, and can now have
a number of independent film models specified.
For example, the hotBoxes tutorial could be modified to have separate
film regions for the boxes and for the floor. In which case, the names
of the separate films would need specifying as shown below.
surfaceFilms
{
type surfaceFilms;
surfaceFilms (boxesFilm floorFilm); // <-- new entry
libs ("libsurfaceFilmModels.so");
}
The old fvModel name, surfaceFilm, has been maintained for backwards
compatibility.
The Lagrangian surface film model now also requires the coupled
surfaceFilms to be specified when there is not just a single
default-named film. For example, in constant/cloudProperties:
subModels
{
surfaceFilmModel thermoSurfaceFilm;
thermoSurfaceFilmCoeffs
{
surfaceFilms (boxesFilm floorFilm); // <-- new entry
interactionType splashBai;
deltaWet 0.0005;
Adry 2630;
Awet 1320;
Cf 0.6;
}
...
}
This change resolves a mass-conservation issue caused by the handling of
absolute and relative fluxes in the construction of the transonic pressure
equation.
to handle isotropic and anisotropic is a consistent, general and extensible
manner, replacing the horrible hacks which were in solidThermo.
This is entirely consistent with thermophysicalTransportModel for fluids and
provides the q() and divq() for the solid energy conservation equations. The
transport model and properties are specified in the optional
thermophysicalTransport dictionary, the default model being isotropic if this
dictionary file is not present, thus providing complete backward-compatibility
for the common isotropic cases.
Anisotropic thermal conductivity is now handled in a much more general manner by
the anisotropic model:
Class
Foam::solidThermophysicalTransportModels::anisotropic
Description
Solid thermophysical transport model for anisotropic thermal conductivity
The anisotropic thermal conductivity field is evaluated from the solid
material anisotropic kappa specified in the physicalProperties dictionary
transformed into the global coordinate system using default
coordinate system and optionally additional coordinate systems specified
per-zone in the thermophysicalProperties dictionary.
Usage
Example of the anisotropic thermal conductivity specification in
thermophysicalProperties with two zone-based coordinate systems in
addition to the default:
\verbatim
model anisotropic;
// Default coordinate system
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type cylindrical;
e3 (1 0 0);
}
}
// Optional zone coordinate systems
zones
{
coil1
{
type cartesian;
origin (0.1 0.2 0.7);
coordinateRotation
{
type cylindrical;
e3 (0.5 0.866 0);
}
}
coil2
{
type cartesian;
origin (0.4 0.5 1);
coordinateRotation
{
type cylindrical;
e3 (0.866 0.5 0);
}
}
}
\endverbatim
This development required substantial rationalisation of solidThermo,
coordinateSystems and updates to the solid solver module, solidDisplacementFoam,
the wallHeatFlux functionObject, thermalBaffle and all coupled thermal boundary
conditions.
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.
Replacing the specific twoPhaseChangeModel with a consistent and general fvModel
interface will support not just cavitation using the new compressible
VoFCavitation fvModel but also other phase-change and interface manipulation
models in the future and is easier to use for case-specific and other user
customisation.
Class
Foam::fv::compressible::VoFCavitation
Description
Cavitation fvModel
Usage
Example usage:
\verbatim
VoFCavitation
{
type VoFCavitation;
libs ("libcompressibleVoFCavitation.so");
model SchnerrSauer;
KunzCoeffs
{
pSat 2300; // Saturation pressure
UInf 20.0;
tInf 0.005; // L = 0.1 m
Cc 1000;
Cv 1000;
}
MerkleCoeffs
{
pSat 2300; // Saturation pressure
UInf 20.0;
tInf 0.005; // L = 0.1 m
Cc 80;
Cv 1e-03;
}
SchnerrSauerCoeffs
{
pSat 2300; // Saturation pressure
n 1.6e+13;
dNuc 2.0e-06;
Cc 1;
Cv 1;
}
}
\endverbatim
The cavitating ballValve tutorial has been updated to use the new VoFCavitation
fvModel.
Replacing the specific twoPhaseChangeModel with a consistent and general fvModel
interface will support not just cavitation using the new VoFCavitation fvModel
but also other phase-change and interface manipulation models in the future and
is easier to use for case-specific and other user customisation.
rather than p_rgh which introduces an imbalance between the pressure and
buoyancy forces. The relaxation factor for p_rgh specified in fvSolution is
used to relax the net force as the intent is to relax the pressure and this
provides convenient usage and backwards-compatibility.
Optional relaxation for the thermodynamic pressure p is also available for case
this provides convergence benefit for steady cases by relaxing the pressure work
term is the energy equation.
Note these changes only relate to the operation of the isothermalFluid solver
module for buoyant cases.
to regain the behaviour of rhoPimpleFoam in OpenFOAM-9 which is more robust than
the potentially more consistent and accurate flux correction approach in
OpenFOAM-10.
