fvMesh::update() now executes at the beginning of the time-step, before time is
incremented and handles topology change, mesh to mesh mapping and redistribution
without point motion. Following each of these mesh changes fields are mapped
from the previous mesh state to new mesh state in a conservative manner. These
mesh changes not occur at most once per time-step.
fvMesh::move() is executed after time is incremented and handles point motion
mesh morphing during the time-step in an Arbitrary Lagrangian Eulerian approach
requiring the mesh motion flux to match the cell volume change. fvMesh::move()
can be called any number of times during the time-step to allow iterative update
of the coupling between the mesh motion and field solution.
This is a map data structure rather than a class or function which performs the
mapping operation so polyMeshDistributionMap is more logical and comprehensible
than mapDistributePolyMesh.
fvMesh is no longer derived from fvSchemes and fvSolution, these are now
demand-driven and accessed by the member functions schemes() and solution()
respectively. This means that the system/fvSchemes and system/fvSolution files
are no longer required during fvMesh constructions simplifying the mesh
generation and manipulation phase; theses files are read on the first call of
their access functions.
The fvSchemes member function names have also been simplified taking advantage
of the context in which they are called, for example
mesh.ddtScheme(fieldName) -> mesh.schemes().ddt(fieldName)
An optional Function1 can now be supplied to a fixedValueConstraint
which controls what proportion of the constraint is applied. This can be
used to ramp, pulse, or limit the duration of the constraint. For
example, ramping up of the constraint could be specified as follows:
scalarSource
{
type fixedValueConstraint;
selectionMode points;
points ((0 0.1 0));
fieldValues
{
s 1;
}
fraction
{
type ramp;
duration 0.1;
}
}
when evaluating the external total pressure from the static pressure and
tangential velocity. This improves numerical stability and solution smoothness
for compressible cases.
The external pressure p0 is now formally the static pressure in the presence of
tangential flow and the corresponding total pressure is calculated from this
static pressure using the tangential velocity obtained from the
pressureInletOutletVelocity boundary condition if available. In the case that
there is no external tangential flow the external total pressure is equal to the
static pressure p0 as before.
Description
Inflow, outflow and entrainment pressure boundary condition based on a
constant total pressure assumption.
For outflow the patch pressure is set to the external static pressure.
For inflow the patch pressure is evaluated from the patch velocity and the
external total pressure obtained from the external static pressure \c p_0
and external velocity \c U_0 which is looked-up from the the optional \c
tangentialVelocity entry in the \c pressureInletOutletVelocity velocity
boundary condition for the patch if that boundary condition is used,
otherwise \c U_0 is assumed zero and the external total pressure is equal to
the external static pressure.
The patch pressure is evaluated from the external conditions using one of
the following expressions depending on the flow conditions and
specification of compressibility:
1. incompressible subsonic:
\f[
p_p = p_0 + 0.5 |U_0|^2 - 0.5 |U|^2
\f]
where
\vartable
p_p | pressure at patch [m^2/s^2]
p_0 | external static pressure [m^2/s^2]
U | velocity [m/s]
U_0 | external velocity [m/s]
\endvartable
2. compressible subsonic:
\f[
p_p = p_0 + 0.5 \rho |U_0|^2 - 0.5 \rho |U|^2
\f]
where
\vartable
p_p | pressure at patch [Pa]
p_0 | external static pressure [Pa]
\rho | density [kg/m^3]
U | velocity [m/s]
U_0 | external velocity [m/s]
\endvartable
3. compressible transonic (\f$\gamma = 1\f$):
\f[
p_p = \frac{p_0 + 0.5 \rho |U_0|^2}{1 + 0.5 \psi |U|^2}
\f]
where
\vartable
p_p | pressure at patch [Pa]
p_0 | external static pressure [Pa]
\psi | compressibility [m^2/s^2]
\rho | density [kg/m^3]
U | velocity [m/s]
U_0 | external velocity [m/s]
\endvartable
4. compressible supersonic (\f$\gamma > 1\f$):
\f[
p_p = \frac{p_0 + 0.5 \rho |U_0|^2}
{(1 + 0.5 \psi G |U|^2)^{\frac{1}{G}}}
\f]
where
\vartable
p_p | pressure at patch [Pa]
p_0 | external static pressure [Pa]
\psi | compressibility [m^2/s^2]
\rho | density [kg/m^3]
G | coefficient given by \f$\frac{\gamma}{1-\gamma}\f$ []
\gamma | ratio of specific heats (Cp/Cv) []
U | velocity [m/s]
U_0 | external velocity [m/s]
\endvartable
The modes of operation are set by the dimensions of the pressure field
to which this boundary condition is applied, the \c psi entry and the value
of \c gamma:
\table
Mode | dimensions | psi | gamma
incompressible subsonic | p/rho | |
compressible subsonic | p | none |
compressible transonic | p | psi | 1
compressible supersonic | p | psi | > 1
\endtable
Usage
\table
Property | Description | Required | Default value
U | Velocity field name | no | U
phi | Flux field name | no | phi
rho | Density field name | no | rho
psi | Compressibility field name | no | none
gamma | (Cp/Cv) | no | 1
p0 | External pressure | yes |
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type totalPressure;
p0 uniform 1e5;
}
\endverbatim
When the optional tangentialVelocity is specified for the
pressureInletOutletVelocity it typically relates to a translating coordinate
transformation, e.g. for a towing-tank simulation, and does not contribute to
the real free-stream total-pressure. Thus in order to get better behaviour from
the totalPressure BC for reversing flow at an entrainment boundary with
tangentialVelocity specified this velocity is subtracted from the extrapolated
velocity when calculating the kinematic contribution to the total pressure.
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.
