The unreliable extrapolateProfile option has been replaced by the more flexible
and reliable profile option which allows the velocity profile to be specified as
a Function1 of the normalised distance to the wall. To simplify the
specification of the most common velocity profiles the new laminarBL (quadratic
profile) and turbulentBL (1/7th power law) Function1s are provided.
In addition to the new profile option the flow rate can now be specified as a
meanVelocity, volumetricFlowRate or massFlowRate, all of which are Function1s of
time.
The following tutorials have been updated to use the laminarBL profile:
multiphase/multiphaseEulerFoam/laminar/titaniaSynthesis
multiphase/multiphaseEulerFoam/laminar/titaniaSynthesisSurface
The following tutorials have been updated to use the turbulentBL profile:
combustion/reactingFoam/Lagrangian/verticalChannel
combustion/reactingFoam/Lagrangian/verticalChannelLTS
combustion/reactingFoam/Lagrangian/verticalChannelSteady
compressible/rhoPimpleFoam/RAS/angledDuct
compressible/rhoPimpleFoam/RAS/angledDuctLTS
compressible/rhoPimpleFoam/RAS/squareBendLiq
compressible/rhoPorousSimpleFoam/angledDuctImplicit
compressible/rhoSimpleFoam/angledDuctExplicitFixedCoeff
compressible/rhoSimpleFoam/squareBend
compressible/rhoSimpleFoam/squareBendLiq
heatTransfer/chtMultiRegionFoam/shellAndTubeHeatExchanger
heatTransfer/chtMultiRegionFoam/shellAndTubeHeatExchanger
incompressible/porousSimpleFoam/angledDuctImplicit
incompressible/porousSimpleFoam/straightDuctImplicit
multiphase/interFoam/RAS/angledDuct
Class
Foam::flowRateInletVelocityFvPatchVectorField
Description
Velocity inlet boundary condition creating a velocity field with
optionally specified profile normal to the patch adjusted to match the
specified mass flow rate, volumetric flow rate or mean velocity.
For a mass-based flux:
- the flow rate should be provided in kg/s
- if \c rho is "none" the flow rate is in m3/s
- otherwise \c rho should correspond to the name of the density field
- if the density field cannot be found in the database, the user must
specify the inlet density using the \c rhoInlet entry
For a volumetric-based flux:
- the flow rate is in m3/s
Usage
\table
Property | Description | Required | Default value
massFlowRate | Mass flow rate [kg/s] | no |
volumetricFlowRate | Volumetric flow rate [m^3/s]| no |
meanVelocity | Mean velocity [m/s]| no |
profile | Velocity profile | no |
rho | Density field name | no | rho
rhoInlet | Inlet density | no |
alpha | Volume fraction field name | no |
\endtable
Example of the boundary condition specification for a volumetric flow rate:
\verbatim
<patchName>
{
type flowRateInletVelocity;
volumetricFlowRate 0.2;
profile laminarBL;
}
\endverbatim
Example of the boundary condition specification for a mass flow rate:
\verbatim
<patchName>
{
type flowRateInletVelocity;
massFlowRate 0.2;
profile turbulentBL;
rho rho;
rhoInlet 1.0;
}
\endverbatim
Example of the boundary condition specification for a volumetric flow rate:
\verbatim
<patchName>
{
type flowRateInletVelocity;
meanVelocity 5;
profile turbulentBL;
}
\endverbatim
The \c volumetricFlowRate, \c massFlowRate or \c meanVelocity entries are
\c Function1 of time, see Foam::Function1s.
The \c profile entry is a \c Function1 of the normalised distance to the
wall. Any suitable Foam::Function1s can be used including
Foam::Function1s::codedFunction1 but Foam::Function1s::laminarBL and
Foam::Function1s::turbulentBL have been created specifically for this
purpose and are likely to be appropriate for most cases.
Note
- \c rhoInlet is required for the case of a mass flow rate, where the
density field is not available at start-up
- The value is positive into the domain (as an inlet)
- May not work correctly for transonic inlets
- Strange behaviour with potentialFoam since the U equation is not solved
See also
Foam::fixedValueFvPatchField
Foam::Function1s::laminarBL
Foam::Function1s::turbulentBL
Foam::Function1s
Foam::flowRateOutletVelocityFvPatchVectorField
to provide a single consistent code and user interface to the specification of
physical properties in both single-phase and multi-phase solvers. This redesign
simplifies usage and reduces code duplication in run-time selectable solver
options such as 'functionObjects' and 'fvModels'.
* physicalProperties
Single abstract base-class for all fluid and solid physical property classes.
Physical properties for a single fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties' dictionary.
Physical properties for a phase fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties.<phase>' dictionary.
This replaces the previous inconsistent naming convention of
'transportProperties' for incompressible solvers and
'thermophysicalProperties' for compressible solvers.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the
'physicalProperties' dictionary does not exist.
* phaseProperties
All multi-phase solvers (VoF and Euler-Euler) now read the list of phases and
interfacial models and coefficients from the
'constant/<region>/phaseProperties' dictionary.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the 'phaseProperties'
dictionary does not exist. For incompressible VoF solvers the
'transportProperties' is automatically upgraded to 'phaseProperties' and the
two 'physicalProperties.<phase>' dictionary for the phase properties.
* viscosity
Abstract base-class (interface) for all fluids.
Having a single interface for the viscosity of all types of fluids facilitated
a substantial simplification of the 'momentumTransport' library, avoiding the
need for a layer of templating and providing total consistency between
incompressible/compressible and single-phase/multi-phase laminar, RAS and LES
momentum transport models. This allows the generalised Newtonian viscosity
models to be used in the same form within laminar as well as RAS and LES
momentum transport closures in any solver. Strain-rate dependent viscosity
modelling is particularly useful with low-Reynolds number turbulence closures
for non-Newtonian fluids where the effect of bulk shear near the walls on the
viscosity is a dominant effect. Within this framework it would also be
possible to implement generalised Newtonian models dependent on turbulent as
well as mean strain-rate if suitable model formulations are available.
* visosityModel
Run-time selectable Newtonian viscosity model for incompressible fluids
providing the 'viscosity' interface for 'momentumTransport' models.
Currently a 'constant' Newtonian viscosity model is provided but the structure
supports more complex functions of time, space and fields registered to the
region database.
Strain-rate dependent non-Newtonian viscosity models have been removed from
this level and handled in a more general way within the 'momentumTransport'
library, see section 'viscosity' above.
The 'constant' viscosity model is selected in the 'physicalProperties'
dictionary by
viscosityModel constant;
which is equivalent to the previous entry in the 'transportProperties'
dictionary
transportModel Newtonian;
but backward-compatibility is provided for both the keyword and model
type.
* thermophysicalModels
To avoid propagating the unnecessary constructors from 'dictionary' into the
new 'physicalProperties' abstract base-class this entire structure has been
removed from the 'thermophysicalModels' library. The only use for this
constructor was in 'thermalBaffle' which now reads the 'physicalProperties'
dictionary from the baffle region directory which is far simpler and more
consistent and significantly reduces the amount of constructor code in the
'thermophysicalModels' library.
* compressibleInterFoam
The creation of the 'viscosity' interface for the 'momentumTransport' models
allows the complex 'twoPhaseMixtureThermo' derived from 'rhoThermo' to be
replaced with the much simpler 'compressibleTwoPhaseMixture' derived from the
'viscosity' interface, avoiding the myriad of unused thermodynamic functions
required by 'rhoThermo' to be defined for the mixture.
Same for 'compressibleMultiphaseMixture' in 'compressibleMultiphaseInterFoam'.
This is a significant improvement in code and input consistency, simplifying
maintenance and further development as well as enhancing usability.
Henry G. Weller
CFD Direct Ltd.
The FOAM file format has not changed from version 2.0 in many years and so there
is no longer a need for the 'version' entry in the FoamFile header to be
required and to reduce unnecessary clutter it is now optional, defaulting to the
current file format 2.0.
The new fvModels is a general interface to optional physical models in the
finite volume framework, providing sources to the governing conservation
equations, thus ensuring consistency and conservation. This structure is used
not only for simple sources and forces but also provides a general run-time
selection interface for more complex models such as radiation and film, in the
future this will be extended to Lagrangian, reaction, combustion etc. For such
complex models the 'correct()' function is provided to update the state of these
models at the beginning of the PIMPLE loop.
fvModels are specified in the optional constant/fvModels dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The new fvConstraints is a general interface to optional numerical constraints
applied to the matrices of the governing equations after construction and/or to
the resulting field after solution. This system allows arbitrary changes to
either the matrix or solution to ensure numerical or other constraints and hence
violates consistency with the governing equations and conservation but it often
useful to ensure numerical stability, particularly during the initial start-up
period of a run. Complex manipulations can be achieved with fvConstraints, for
example 'meanVelocityForce' used to maintain a specified mean velocity in a
cyclic channel by manipulating the momentum matrix and the velocity solution.
fvConstraints are specified in the optional system/fvConstraints dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The separation of fvOptions into fvModels and fvConstraints provides a rational
and consistent separation between physical and numerical models which is easier
to understand and reason about, avoids the confusing issue of location of the
controlling dictionary file, improves maintainability and easier to extend to
handle current and future requirements for optional complex physical models and
numerical constraints.
A new run-time selectable interface compression scheme framework has been added
to the two-phase VoF solvers to provide greater flexibility, extensibility and
more consistent user-interface. The previously built-in interface compression
is now in the standard run-time selectable surfaceInterpolationScheme
interfaceCompression:
Class
Foam::interfaceCompression
Description
Interface compression corrected scheme, based on counter-gradient
transport, to maintain sharp interfaces during VoF simulations.
The interface compression is applied to the face interpolated field from a
suitable 2nd-order shape-preserving NVD or TVD scheme, e.g. vanLeer or
vanAlbada. A coefficient is supplied to control the degree of compression,
with a value of 1 suitable for most VoF cases to ensure interface integrity.
A value larger than 1 can be used but the additional compression can bias
the interface to follow the mesh more closely while a value smaller than 1
can lead to interface smearing.
Example:
\verbatim
divSchemes
{
.
.
div(phi,alpha) Gauss interfaceCompression vanLeer 1;
.
.
}
\endverbatim
The separate scheme for the interface compression term "div(phirb,alpha)" is no
longer required or used nor is the compression coefficient cAlpha in fvSolution
as this is now part of the "div(phi,alpha)" scheme specification as shown above.
Backward-compatibility is provided by checking the specified "div(phi,alpha)"
scheme against the known interface compression schemes and if it is not one of
those the new interfaceCompression scheme is used with the cAlpha value
specified in fvSolution.
More details can be found here:
https://cfd.direct/openfoam/free-software/multiphase-interface-capturing
Henry G. Weller
CFD Direct Ltd.
Following the generalisation of the TurbulenceModels library to support
non-Newtonian laminar flow including visco-elasticity and extensible to other
form of non-Newtonian behaviour the name TurbulenceModels is misleading and does
not properly represent how general the OpenFOAM solvers now are. The
TurbulenceModels now provides an interface to momentum transport modelling in
general and the plan is to rename it MomentumTransportModels and in preparation
for this the turbulenceProperties dictionary has been renamed momentumTransport
to properly reflect its new more general purpose.
The old turbulenceProperties name is supported for backward-compatibility.
renaming the legacy keywords
RASModel -> model
LESModel -> model
laminarModel -> model
which is simpler and clear within the context in which they are specified, e.g.
RAS
{
model kOmegaSST;
turbulence on;
printCoeffs on;
}
rather than
RAS
{
RASModel kOmegaSST;
turbulence on;
printCoeffs on;
}
The old keywords are supported for backward compatibility.
Rather than defining patches for all external block faces to provide name and
type use the defaultPatch entry to collect undefined faces into a single named
and typed patch, e.g.
defaultPatch
{
name walls;
type wall;
}
For example the actuationDiskSource fvOption may now be specified
disk1
{
type actuationDiskSource;
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
rather than
disk1
{
type actuationDiskSource;
active on;
actuationDiskSourceCoeffs
{
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
}
but this form is supported for backward compatibility.
