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
This correction applies to the handling of the implicit part of the matrix for
the segregates solution of the tensor components, e.g. when solving for the
Reynolds stress in cases with rotated cyclic patches.
Pressure reduction is now applied only for entrained flow, fixed pressure is
applied to outflow to improve stability for complex recirculating flow exiting
the domain. This is the same approach used in the totalPressure boundary
condition.
Description
This boundary condition provides an entrainment condition for pressure
including support for supersonic jets exiting the domain.
Usage
\table
Property | Description | Required | Default value
rho | Density field name | no | rho
psi | Compressibility field name | no | thermo:psi
gamma | Heat capacity ratio (cp/Cv) | yes |
phi | Flux field name | no | phi
p0 | Reference pressure | yes |
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type transonicEntrainmentPressure;
gamma 1.4;
p0 uniform 1e5;
}
\endverbatim
See also
Foam::entrainmentPressureFvPatchScalarField
Foam::mixedFvPatchField
This boundary condition specifies a slip velocity on moving walls. It
works similarly to movingWallVelocity, except that the tangential
velocity is not constrained. It can be specified as follows:
<patchName>
{
type movingWallSlipVelocity;
value uniform (0 0 0); // Initial value
}
MULES no longer synchronises the limiter field using syncTools. Surface
boundary field synchronisation is now done with a surface-field-specific
communication procedure that should result in scaling benefits relative
to syncTools. This change also means that the limiter does not need to
be continuous face field which is then sliced; it can be a standard
surface field.
replacing the virtual functions overridden in engineTime.
Now the userTime conversion function in Time is specified in system/controlDict
such that the solver as well as all pre- and post-processing tools also operate
correctly with the chosen user-time.
For example the user-time and rpm in the tutorials/combustion/XiEngineFoam/kivaTest case are
now specified in system/controlDict:
userTime
{
type engine;
rpm 1500;
}
The default specification is real-time:
userTime
{
type real;
}
but this entry can be omitted as the real-time class is instantiated
automatically if the userTime entry is not present in system/controlDict.
It is now possible to use waveVelocity and waveAlpha boundary conditions
in cases in which the waves generate localised flow reversals along the
boundary. This means waves can be speficied at arbitrary directions and
with zero mean flow. Previously and integral approach, similar to
flowRateOutlet, was used, which was only correct when the direction of
wave propagation was aligned with the boundary normal.
This improvement has been achieved by reformulating the waveVelocity and
waveAlpha boundary conditions in terms of a new fixedValueInletOutlet
boundary condition type. This condition enforces a fixed value in all
cases except that of advection terms in the presence of outflow. In this
configuration a gradient condition is applied that will relax towards
the desired fixed value.
The wavePressure boundary condition has been removed, as it is no longer
necessary or advisable to locally switch between velocity and pressure
formulations along a wave boundary. Wave boundaries should now have the
general fixedFluxPressure or fixedFluxExtrapolatedPressure conditions
applied to the pressure field.
Two new tutorial cases have been created to demonstrate the new
functionality. The multiphase/interFoam/laminar/wave3D case demonstrates
wave generation with zero mean flow and at arbitrary angles to the
boundaries, and incompressible/pimpleFoam/RAS/waveSubSurface
demonstrates usage for sub-surface problems.
The patchType override logic has been simplified and made consistent
between fv, fvs and point patch fields. The "constraintType" attribute
has been removed from point fields as it was not being used.
This change fixes failures that occur with the mapping of fields with
patchType overrides. It fixes a crash that previously occurred when
redistributing patch fields with patchType overrides. It also makes
decomposition correctly maintain patchType overrides on cyclics when
those cyclics are separated and become processorCyclics.
These fixes have been achieved by removing the patchType override data
from the fv and point patches. Whether or not the field overrides the
underlying patchType constraint is now determined on the fly from the
patch and field names and what is available on the field run-time
selection table.
to differentiate between flux field which require face-flipping and
non-extensive surface fields which do not. Currently flux fields are
distinguished by being surfaceScalarField with dimensions of either volumetric
or mass flux.
This change corrects the handling of the surfaceVectorField Uf which was
previously mapped incorrectly on faces requiring the flipping of the flux
orientation.
This new constraint type is preferable to the 'empty' type used previously as it
support patch field values for post-processing and other purposes.
The internalFvPatchField operates as a 'zeroGradient' type so that the adjacent
cell values are displayed on the faces exposed by the sub-setting.
The internalFvsPatchField operates as a 'calculated' type so that the internal
face values are displayed on the faces exposed by the sub-setting.
The immediate benefit of this change can be seen when using 'subsetMesh' without
the '-noFields' option to create and write a sub-set of an 'fvMesh' with field
values, now the face values of the 'exposed' internal faces can be visualised.
TableBase, TableFile and Table now combined into a single simpler Table class
which handle both the reading of embedded and file data using the generalised
TableReader. The new EmbeddedTableReader handles the embedded data reading
providing the functionality of the original Table class within the same
structure that can read the data from separate files.
The input format defaults to 'embedded' unless the 'file' entry is present and
the Table class is added to the run-time selection table under the name 'table'
and 'tableFile' which provides complete backward comparability. However it is
advisable to migrate cases to use the new 'table' entry and all tutorial cases
have been updated.
While calculatedFvPatchField would be considered as a BC which fixes the value
during solution it cannot be used for that purpose and under all other
conditions it does not fix the boundary value as the '=' operator changes the
value. However calculatedFvPatchField is used for the reference phase in
multiphase systems and if it is considered to fix the boundary value it interferes
with the operation of the MULES limiter and hence it is far preferable if it
does not fix the value.
providing the shear-stress term in the momentum equation for incompressible and
compressible Newtonian, non-Newtonian and visco-elastic laminar flow as well as
Reynolds averaged and large-eddy simulation of turbulent flow.
The general deviatoric shear-stress term provided by the MomentumTransportModels
library is named divDevTau for compressible flow and divDevSigma (sigma =
tau/rho) for incompressible flow, the spherical part of the shear-stress is
assumed to be either included in the pressure or handled separately. The
corresponding stress function sigma is also provided which in the case of
Reynolds stress closure returns the effective Reynolds stress (including the
laminar contribution) or for other Reynolds averaged or large-eddy turbulence
closures returns the modelled Reynolds stress or sub-grid stress respectively.
For visco-elastic flow the sigma function returns the effective total stress
including the visco-elastic and Newtonian contributions.
For thermal flow the heat-flux generated by thermal diffusion is now handled by
the separate ThermophysicalTransportModels library allowing independent run-time
selection of the heat-flux model.
During the development of the MomentumTransportModels library significant effort
has been put into rationalising the components and supporting libraries,
removing redundant code, updating names to provide a more logical, consistent
and extensible interface and aid further development and maintenance. All
solvers and tutorials have been updated correspondingly and backward
compatibility of the input dictionaries provided.
Henry G. Weller
CFD Direct Ltd.
