which can be selected and executed in foamMultiRun for complex CHT cases. This
is a much more general, flexible, extensible and maintainable structure than the
now deprecated regionModels system and associated clutter.
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.
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.
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.
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.
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.
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.
These tutorials now make make use of the phaseTurbulenceStabilisation
fvModel and the wallBoilingProperties functionObject.
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
No advantage was found in the specific snappyHexMesh settings previously
specified for this case. This case now uses settings from the standard
snappyHexMesh.cfg file.
The rotating region has also been modified to align better with the
original block mesh. For sliding interface problems this is important in
order to reliably get good conformance to the cylinder edges.
After direct and regular expression matching the scheme name is now filtered to
remove and group/phase extensions in the name and matched again with the schemes
dictionary.
This significantly simplifies the specification of schemes in multiphase
simulations, instead of the rather messy regular expressions the new method
allows schemes to be specified without the group/phase name extension and the
scheme is then used for all groups/phases. For example in the bubbleColumn
tutorials the schemes can now be specified thus:
divSchemes
{
default none;
div(phi,alpha) Gauss vanLeer;
div(phir,alpha,alpha) Gauss vanLeer;
div(alphaRhoPhi,U) Gauss limitedLinearV 1;
div(phi,U) Gauss limitedLinearV 1;
div(alphaRhoPhi,e) Gauss limitedLinear 1;
div(alphaRhoPhi,K) Gauss limitedLinear 1;
div(alphaRhoPhi,(p|rho)) Gauss limitedLinear 1;
div((((alpha*rho)*nuEff)*dev2(T(grad(U))))) Gauss linear;
}
rather than using complex regular expressions as done previously:
divSchemes
{
default none;
div(phi,alpha.air) Gauss vanLeer;
div(phi,alpha.water) Gauss vanLeer;
div(phir,alpha.water,alpha.air) Gauss vanLeer;
div(phir,alpha.air,alpha.water) Gauss vanLeer;
"div\(alphaRhoPhi.*,U.*\)" Gauss limitedLinearV 1;
"div\(phi.*,U.*\)" Gauss limitedLinearV 1;
"div\(alphaRhoPhi.*,(h|e).*\)" Gauss limitedLinear 1;
"div\(alphaRhoPhi.*,K.*\)" Gauss limitedLinear 1;
"div\(alphaRhoPhi.*,\(p\|rho.*\)\)" Gauss limitedLinear 1;
"div\(alphaRhoPhi.*,\(p\|rho.*\)\)" Gauss limitedLinear 1;
"div\(\(\(\(alpha.*\*rho.*\)*nuEff.*\)\*dev2\(T\(grad\(U.*\)\)\)\)\)" Gauss linear;
}
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.
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 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 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.
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;
}
...
}
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.
to enable writing of the isotropicDamping:forceCoeff isotropicDamping:scale
waveForcing:forceCoeff waveForcing:scale diagnostic fields to check the damping
and forcing distributions.
Lagrangian is now compatible with the meshToMesh topology changer. If a
cloud is being simulated and this topology changer is active, then the
cloud data will be automatically mapped between the specified sequence
of meshes in the same way as the finite volume data. This works both for
serial and parallel simulations.
In addition, mapFieldsPar now also supports mapping of Lagrangian data
when run in parallel.
Renamed classes:
turbulentTemperatureCoupledBaffleMixedFvPatchScalarField ->
coupledTemperatureFvPatchScalarField
externalWallHeatFluxTemperatureFvPatchScalarField ->
externalTemperatureFvPatchScalarField
Radiation heat-flux support in turbulentTemperatureRadCoupledMixed transferred
to coupledTemperatureFvPatchScalarField and turbulentTemperatureRadCoupledMixed removed.
Renamed boundary condition type names in T field files:
compressible::turbulentTemperatureCoupledBaffleMixed -> coupledTemperature
compressible::turbulentTemperatureRadCoupledMixed -> coupledTemperature
compressible::externalWallHeatFluxTemperature -> externalTemperature
Backward-compatibility is provided for all three of the above BC specifications
so existing cases will run as before but we recommend migrating to the new
simpler names.
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.
and demonstrates the wave being generated in a region adjacent to the outlet and
propagating upstream towards the inlet where it is damped by a damping region
and mesh expansion.
to avoid further confusion concerning the origin of the thermo and transport
data which is not that supplied with the GRI mechanism as the these simple test
cases is to demonstrate the integration of a complex mechanism with or without
TDAC and ISAT, not complex transport modelling.
The proposed change does not change the mixing rules and the default coefficient mixing approach does not
provide mixed properties consistent with the GRI specification. The purpose of these simple test cases
is to demonstrate the integration of a complex mechanism with or without TDAC and ISAT, not complex transport modelling.
A new tutorial is required to demonstrate the GRI 3.0 mechanism with complex transport properties.
This reverts commit 53f3bc6fdd.
With waveForcing waves can be generated with a domain by applying forcing to
both the phase-fraction and velocity fields rather than requiring that the waves
are introduced at an inlet. This provides much greater flexibility as waves can
be generated in any direction relative to the mean flow, obliquely or even
against the flow. isotropicDamping or verticalDamping can be used in
conjunction with waveForcing to damp the waves before they reach an outlet,
alternatively waveForcing can be used in regions surrounding a hull for example
to maintain far-field waves everywhere.
The tutorials/multiphase/interFoam/laminar/forcedWave tutorial case is provided
to demonstrate the waveForcing fvModel as an alternative to the wave inlet
boundary conditions used in the tutorials/multiphase/interFoam/laminar/wave
case.
Class
Foam::fv::waveForcing
Description
This fvModel applies forcing to the liquid phase-fraction field and all
components of the vector field to relax the fields towards those
calculated from the current wave distribution.
The forcing force coefficient \f$\lambda\f$ should be set based on the
desired level of forcing and the residence time the waves through the
forcing zone. For example, if waves moving at 2 [m/s] are travelling
through a forcing zone 8 [m] in length, then the residence time is 4 [s]. If
it is deemed necessary to force for 5 time-scales, then \f$\lambda\f$ should
be set to equal 5/(4 [s]) = 1.2 [1/s].
Usage
Example usage:
\verbatim
waveForcing1
{
type waveForcing;
libs ("libwaves.so");
liquidPhase water;
// Define the line along which to apply the graduation
origin (600 0 0);
direction (-1 0 0);
// // Or, define multiple lines
// origins ((600 0 0) (600 -300 0) (600 300 0));
// directions ((-1 0 0) (0 1 0) (0 -1 0));
scale
{
type halfCosineRamp;
start 0;
duration 300;
}
lambda 0.5; // Forcing coefficient
}
\endverbatim
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.
