genericPatches is linked into mesh generation and manipulation utilities but not
solvers so that the solvers now check for the availability of the specified
patch types. Bugs in the tutorials exposed by this check have been corrected.
The keyword 'select' is now used to specify the cell, face or point set
selection method consistently across all classes requiring this functionality.
'select' replaces the inconsistently named 'regionType' and 'selectionMode'
keywords used previously but backwards-compatibility is provided for user
convenience. All configuration files and tutorials have been updated.
Examples of 'select' from the tutorial cases:
functionObjects:
cellZoneAverage
{
type volFieldValue;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
writeInterval 1;
fields (p);
select cellZone;
cellZone injection;
operation volAverage;
writeFields false;
}
#includeFunc populationBalanceSizeDistribution
(
name=numberDensity,
populationBalance=aggregates,
select=cellZone,
cellZone=outlet,
functionType=numberDensity,
coordinateType=projectedAreaDiameter,
allCoordinates=yes,
normalise=yes,
logTransform=yes
)
fvModel:
cylinderHeat
{
type heatSource;
select all;
q 5e7;
}
fvConstraint:
momentumForce
{
type meanVelocityForce;
select all;
Ubar (0.1335 0 0);
}
This is a more intuitive keyword than "funcName" or "entryName". A
function object's name and corresponding output directory can now be
renamed as follows:
#includeFunc patchAverage
(
name=cylinderT, // <-- was funcName=... or entryName=...
region=fluid,
patch=fluid_to_solid,
field=T
)
Some packaged functions previously relied on a "name" argument that
related to an aspect of the function; e.g., the name of the faceZone
used by the faceZoneFlowRate function. These have been disambiguated.
This has also made them consistent with the preferred input syntax of
the underlying function objects.
Examples of the changed #includeFunc entries are shown below:
#includeFunc faceZoneAverage
(
faceZone=f0, // <-- was name=f0
U
)
#includeFunc faceZoneFlowRate
(
faceZone=f0 // <-- was name=f0
)
#includeFunc populationBalanceSizeDistribution
(
populationBalance=bubbles,
regionType=cellZone,
cellZone=injection, // <-- was name=injection
functionType=volumeDensity,
coordinateType=diameter,
normalise=yes
)
#includeFunc triSurfaceAverage
(
triSurface=mid.obj, // <-- was name=mid.obj
p
)
#includeFunc triSurfaceVolumetricFlowRate
(
triSurface=mid.obj // <-- was name=mid.obj
)
#includeFunc uniform
(
fieldType=volScalarField,
fieldName=alpha, // <-- was name=alpha
dimensions=[0 0 0 0 0 0 0],
value=0.2
)
so that the same option with a rational name is also available for #includeModel
and #includeConstraint. Support for funcName is maintained for
backwards-compatibility.
#includeModel includes an fvModel configuration file into the fvModels file
#includeConstraint includes an fvModel configuration file into the fvConstraints file
These operate in the same manner as #includeFunc does for functionObjects and
search the etc/caseDicts/fvModels and etc/caseDicts/fvConstraints directories
for configuration files and apply optional argument substitution.
Class
Foam::functionEntries::includeFvModelEntry
Description
Specify a fvModel dictionary file to include, expects the
fvModel name to follow with option arguments (without quotes).
Searches for fvModel dictionary file in user/group/shipped
directories allowing for version-specific and version-independent files
using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/caseDicts/fvModels
- ~/.OpenFOAM/caseDicts/fvModels
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/etc/caseDicts/fvModels
- $WM_PROJECT_SITE/etc/caseDicts/fvModels
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/etc/caseDicts/fvModels
- $WM_PROJECT_INST_DIR/site/etc/caseDicts/fvModels
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/caseDicts/fvModels
The optional field arguments included in the name are inserted in 'field' or
'fields' entries in the fvModel dictionary and included in the name
of the fvModel entry to avoid conflict.
Examples:
\verbatim
#includeModel clouds
#includeModel surfaceFilms
\endverbatim
Other dictionary entries may also be specified using named arguments.
See also
Foam::includeFvConstraintEntry
Foam::includeFuncEntry
Class
Foam::functionEntries::includeFvConstraintEntry
Description
Specify a fvConstraint dictionary file to include, expects the
fvConstraint name to follow with option arguments (without quotes).
Searches for fvConstraint dictionary file in user/group/shipped
directories allowing for version-specific and version-independent files
using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/caseDicts/fvConstraints
- ~/.OpenFOAM/caseDicts/fvConstraints
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/etc/caseDicts/fvConstraints
- $WM_PROJECT_SITE/etc/caseDicts/fvConstraints
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/etc/caseDicts/fvConstraints
- $WM_PROJECT_INST_DIR/site/etc/caseDicts/fvConstraints
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/caseDicts/fvConstraints
The optional field arguments included in the name are inserted in 'field' or
'fields' entries in the fvConstraint dictionary and included in the name
of the fvConstraint entry to avoid conflict.
Examples:
\verbatim
#includeConstraint limitPressure(minFactor=0.1, maxFactor=2)
#includeConstraint limitTemperature(min=101, max=1000)
\endverbatim
or for a multiphase case:
\verbatim
#includeConstraint limitLowPressure(min=1e4)
#includeConstraint limitTemperature(phase=steam, min=270, max=2000)
#includeConstraint limitTemperature(phase=water, min=270, max=2000)
\endverbatim
Other dictionary entries may also be specified using named arguments.
See also
Foam::includeFvModelEntry
Foam::includeFuncEntry
Tutorials have been updated to use the new consistent names within the
wall boiling system. The changes are backwards compatible so all
tutorials should run both before and after this change.
This boundary condition now solves for the wall temperature by interval
bisection, which should be significantly more robust than the previous
fixed-point iteration procedure. There is a new non-dimensional
"tolerance" setting that controls how tightly this solution procedure
solves the wall temperature. The "relax" setting is no longer used.
The boundary condition no longer triggers re-evaluation of the
temperature condition in order to re-calculate the heat flux within the
solution iteration. Instead, it extracts physical coefficients from the
form of the boundary condition and uses these to form a linearised
approximation of the heat flux. This is a more general approach, and
will not trigger side-effects associated with re-evaluating the
temperature condition.
The fixedMultiphaseHeatFlux condition has been replaced by a
uniformFixedMultiphaseHeatFlux condition, which constructs a mixed
constraint which portions a specified heat flux between the phases in
such a way as to keep the boundary temperature uniform across all
phases. This can be applied to all phases. It is no longer necessary to
apply a heat flux model to one "master" phase, then map the resulting
temperature to the others. An example specification of this boundary
condition is as follows:
wall
{
type uniformFixedMultiphaseHeatFlux;
q 1000;
relax 0.3;
value $internalField;
}
The wall boiling tutorials have been updated to use these new functions,
and time-varying heat input has been used to replace the
stop-modify-restart pattern present in the single-region cases.
This option means that a one field can be mapped to another within the
same patch without specifying the patch name. E.g.:
walls
{
type mappedValue;
//neighbourPatch walls; // <-- Previously required. Still supported.
samePatch yes; // <-- New alternative specification
field T.liquid;
value $internalField;
}
This is useful when the boundary condition is specified using a regular
expression for the patch name.
"wall_.*"
{
type mappedValue;
//neighbourPatch ???; // <-- No unique name can be given
samePatch yes; // <-- Still works
field T.liquid;
value $internalField;
}
The standard Jayatilleke thermal wall function now permits evaluation
via static functions. The boiling wall function now uses these
functions, thereby removing the phase-Jayatilleke base class and
associated duplication of the Jayatilleke model.
It is now possible to map from one field to another within the same
patch, using the mappedValue boundary condition. The restriction is that
the mapping must be from a different field, otherwise field values are
being assigned to themselves, which produces an undefined result.
The mappedValue boundary condition can now be used in place of the
copiedFixedValue condition in the multiphaseEuler module. The
copiedFixedValue condition has therefore been removed.
In addition, the error messages that result from casting a patch to its
mapping engine (mappedPatchBase) have been standardised, and made more
specific to the situation in which the mapping is applied. It may be
inappropriate, for example, to map within the same region or patch.
These cases are now identified and appropriate error messages are
generated.
The error messages have also been made IO errors, so they now provide
context with regards to the dictionary entries that they relate to.
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
)
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 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.
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.
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
