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 serves as an example of cavitation modelling with the
multiphaseEuler module. This case also contains validation of the
pressure profile along the hydrofoil against experimental data.
Based on a case contributed by Petteri Peltonen, VTT.
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.
These models are intended to provide saturation curves for use in
multiple solvers and sub-models. They can be specified in a similar
manner to function1-s in that value, type or sub-dictionary entries are
all supported. The following specifications for a constant saturation
pressure are all equivalent:
// Value specified. Creates "constant" model.
pSat 8000;
// Type specified. Coefficients provided in the same dictionary.
pSat constant;
value 8000;
// Type specified. Coefficients provided in a coeffs dictionary.
pSat constant;
pSatCoeffs
{
value 8000;
}
// Sub-dictionary specification.
pSat
{
type constant;
value 8000;
}
Supersedes and replaces the tutorials/modules/multiphaseEuler/wallBoiling case
as it is more physical and representative of a real case.
Patch contributed by Juho Peltola, VTT.
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::noSlipFvPatchVectorField
Description
This boundary condition fixes the velocity to zero at walls and assumes
the walls are stationary.
For stationary walls with sliding vertices, e.g. engine liners, the normal
component of the velocity is set from the wall face-flux to ensure
continuity.
Usage
Example of the boundary condition specification:
\verbatim
<patchName>
{
type noSlip;
}
\endverbatim
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.
Class
Foam::MRFslipFvPatchVectorField
Description
Rotating wall-velocity condition to be used for a slip-wall rotating with
the moving frame in an MRF (multi-reference frame) or SRF (single reference
frame) case.
SRF cases are simply MRF cases with a single MRF zone which covers the
entire domain.
Usage
Example of the boundary condition specification for an SRF case or MRF
case with a single zone:
\verbatim
<patchName>
{
type MRFslip;
}
\endverbatim
or if the case has several MRF zones the particular zone this patch is in
must be named explicitly, e.g.:
\verbatim
<patchName>
{
type MRFslip;
MRFZoneName rotor;
}
See also
Foam::MRFPatchField
Foam::MRFZone
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.
The nearest, matching and inverseDistance methods are now based on a
shared "nearby" method. This method creates, for each face, a local
stencil of opposing faces for which the bounding spheres overlap. This
has proven far more robust on cases with both conformal and
non-conformal interfaces.
which is set true if the mesh refinement changed since the last time the
refinement history was written so that it can be written only at the following
write time.
Resolves bug-report https://bugs.openfoam.org/view.php?id=3928
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.
This tutorial's purpose was to demonstrate rebound off an internal
cyclic patch, and thereby "filter" the particles out of the downstream
sections of the geometry. The case does not correctly do this. The patch
interaction handling is incomplete and does not support overriding
cyclic boundary conditions in this way. This tutorial has therefore been
removed pending funding to improve the patch interaction modelling.
Resolves bug report https://bugs.openfoam.org/view.php?id=3923
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.
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.
If the coordinate transformed kappa does not align exactly with the boundary
because the patch face orientations do not conform to the coordinate system
exactly it may be beneficial for convergence and accuracy to enforce
alignment at the boundary by setting the optional \c boundaryAligned to
true.
Usage
Example of the anisotropic thermal conductivity specification in
thermophysicalProperties with two zone-based coordinate systems in
addition to the default:
\verbatim
model anisotropic;
// Force aligned handling of kappa irrespective
// of the calculated patch alignment factors.
boundaryAligned true;
// 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
These tutorials now make make use of the phaseTurbulenceStabilisation
fvModel and the wallBoilingProperties functionObject.
Patch contributed by Juho Peltola, VTT.
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.
