The new optional PIMPLE control transportPredictionFirst is used to select if
the transport modelling predictor is executed ever PIMPLE iteration or only on
the first, which is the default.
Also the transportCorr() function has been renamed correctTransport() for
consistency and the tutorials updated to use the new control name
transportCorrectionFinal instead of the previous name turbOnFinalIterOnly;
support for turbOnFinalIterOnly is maintained for backwards-compatibility.
With the addition of the compressibleInterPhaseThermophysicalTransportModel
thermophysicalTransportModel the compressibleVoF modular solver now support
conjugate heat transfer (CHT).
Th new tutorials/modules/CHT/VoFcoolingCylinder2D tutorial case is provided to
demonstrate this functionality and shows a heated ceramic rod with air flowing
over the top and water underneath.
This function object writes graphs of patch face values, area-averaged in
planes perpendicular to a given direction. It adaptively grades the
distribution of graph points to match the resolution of the mesh.
Example of function object specification:
patchCutLayerAverage1
{
type patchCutLayerAverage;
libs ("libpatchCutLayerAverageFunctionObject.so");
writeControl writeTime;
writeInterval 1;
patch lowerWall;
direction (1 0 0);
nPoints 100;
interpolate no;
fields (p U);
axis x;
setFormat raw;
}
A packaged function object is also included, which permits the following
syntax to be used, either with #includeFunc in the system/controlDict,
or with the -func option to foamPostProcess:
graphPatchCutLayerAverage
(
funcName=aerofoilLowerPressure,
patch=aerofoilLower,
direction=(0.15 -0.016 0),
nPoints=100,
p
)
angleUnits is a more logical name for the user-input as it specifies the units
of the angles written rather than the format of the numbers. The previous name
angleFormat is supported for backwards-compatibility
Class
Foam::functionObjects::rigidBodyState
Description
Writes the rigid body motion state.
Usage
\table
Property | Description | Required | Default value
type | type name: rigidBodyState | yes |
angleUnits | degrees or radians | no | radians
\endtable
Example of function object specification:
\verbatim
rigidBodyState
{
type rigidBodyState;
libs ("librigidBodyState.so");
angleUnits degrees;
}
\endverbatim
Class
Foam::functionObjects::sixDoFRigidBodyState
Description
Writes the 6-DoF motion state.
Example of function object specification:
\verbatim
sixDoFRigidBodyState
{
type sixDoFRigidBodyState;
libs ("libsixDoFRigidBodyState.so");
angleUnits degrees;
}
\endverbatim
Usage
\table
Property | Description | Required | Default value
type | type name: sixDoFRigidBodyState | yes |
angleUnits | degrees or radians | no | radian
\endtable
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.
The localInteraction model now no longer requires specification of an
interaction on any constrained patch type (e.g., symmetry, cyclic, ...).
Non-constrained types (patch, wall, ...) require an interaction to be
specified as before and will trigger an error if this is not the case.
In addition, constrained patches can be overridden by providing a
'patchType' specifier, in the same way as would be done to override a
constrained boundary condition for finite volume.
The filter tutorial now correctly demonstrates something unique; i.e.,
particles rebounding from a cyclic. It has therefore been reinstated.
Resolves (properly) bug report https://bugs.openfoam.org/view.php?id=3923
A set of routines for cutting polyhedra have been added. These can cut
polyhedral cells based on the adjacent point values and an iso-value
which defines the surface. The method operates directly on the
polyhedral cells; it does not decompose them into tetrahedra at any
point. The routines can compute the cut topology as well as integrals of
properties above and below the cut surface.
An iso-surface algorithm has been added based on these polyhedral
cutting routines. It is significantly more robust than the previous
algorithm, and produces compact surfaces equivalent to the previous
algorithm's maximum filtering level. It is also approximately 3 times
faster than the previous algorithm, and 10 times faster when run
repeatedly on the same set of cells (this is because some addressing is
cached and reused).
This algorithm is used by the 'isoSurface', 'distanceSurface' and
'cutPlane' sampled surfaces.
The 'cutPlane' sampled surface is a renaming of 'cuttingPlane' to make
it consistent with the corresponding packaged function. The name
'cuttingPlane' has been retained for backwards compatibility and can
still be used to select a 'cutPlane' surface. The legacy 'plane' surface
has been removed.
The 'average' keyword has been removed from specification of these
sampled surfaces as cell-centred values are no longer used in the
generation of or interpolation to an iso-surface. The 'filtering'
keyword has also been removed as it relates to options within the
previous algorithm. Zone support has been reinstated into the
'isoSurface' sampled surface. Interpolation to all these sampled
surfaces has been corrected to exactly match the user-selected
interpolation scheme, and the interpolation procedure no longer
unnecessarily re-generates data that is already available.
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
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.
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.
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.
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.
The clouds fvModel and all the clouds it creates now contain a full set
of mesh change hooks. Some of these ultimately result in
"NotImplemented" errors, but this is an area under active development
and support may be added in the near future.
In addition, the list of cloud names is now specified from within the
fvModel, using a "clouds" entry. If this entry is omitted then a single
cloud named "cloud" is assumed as before. An example fvModel
specification for multiple clouds might be as follows:
clouds
{
type clouds;
libs ("liblagrangianParcel.so" "liblagrangianParcelTurbulence.so");
clouds (coalCloud limestoneCloud); // <-- New entry. Replaces
// the constant/clouds
// file.
}
Lagrangian solvers that construct clouds explicitly now do so via a new
"parcelClouds" mesh object. This ensures that they, too, are correctly
modified as a result of mesh changes.
Neither mechanism now permits no clouds. If there is not a "clouds"
entry (clouds fvModel), or a constant/clouds file (lagrangian solvers),
and there is not a constant/cloudProperties file for the default cloud,
then an error will be generated. Previously the code executed the solver
with no clouds. Intentional usage of the fvModel or lagrangian solvers
without clouds is considered highly unlikely.
