Simplifications have been made where possible, as permitted by the new
$<type>var syntax. Duplication has been reduced in similar blockMesh
files (e.g., sloshingTank cases). Settings that cannot practically be
changed have been hard-coded (e.g., angle in the mixerVessel2D
blockMeshDict). The rotor2D blockMeshDict has been centralised and
extended to work with an arbitrary number of rotor blades.
This makes the block/edge/face configuration much more similar between
the four different sections of this mesh. It is also useful as it
permits sections to be decativated by commenting them out without
this affecting all the subsequent numbering.
The following examples in the tutorials ($FOAM_TUTORIALS) directory have
been converted from using AMI to the new NCC system:
+ compressible/rhoPimpleFoam/RAS/annularThermalMixer
+ incompressible/pimpleFoam/RAS/propeller
+ lagrangian/particleFoam/mixerVessel2D (formerly mixerVesselAMI2D)
+ multiphase/interFoam/RAS/mixerVessel
+ multiphase/interFoam/RAS/propeller
+ multiphase/multiphaseEulerFoam/laminar/mixerVessel2D (formerly mixerVesselAMI2D)
The following tutorial has been converted from using ACMI:
+ incompressible/pimpleFoam/RAS/oscillatingInlet
The following tutorial has been converted from using Repeat AMI:
+ incompressible/pimpleFoam/RAS/impeller
The following tutorial has been added to demonstrate NCC's ability to
create a sufficiently conservative solution in a closed domain to
maintain phase fraction boundedness:
+ multiphase/interFoam/laminar/mixerVessel2D
The following tutorials have been added to demonstrate NCC's ability to
simulate partially overlapping couples on curved surfaces:
+ incompressible/pimpleFoam/RAS/ballValve
+ multiphase/compressibleInterFoam/RAS/ballValve
The following tutorial has been added to provide a simple comparison of
the conservation behaviour of AMI and NCC:
+ incompressible/pimpleFoam/laminar/nonConformalChannel
The following tutorial has been removed, as there were sufficiently many
examples involving this geometry:
+ incompressible/pimpleFoam/laminar/mixerVesselAMI2D
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
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 themo tables used in wallBoiling have had their Cp/Cv values
corrected, and have been coarsened and reduced in size to bound only the
operating point of the wallBoiling tutorials. They have also been moved
to $FOAM_TUTORIALS/resources/thermoData.
The correction to thermophysical properties has improved the stability
of these cases. As a result it has been possible to reduce the amount of
under-relaxation used in the wall modelling.
so that they operate in the conventional manner in a right-handed coordinate
system:
//- Rotational transformation tensor about the x-axis by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Rx(const scalar& omega)
//- Rotational transformation tensor about the y-axis by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Ry(const scalar& omega)
//- Rotational transformation tensor about the z-axis by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Rz(const scalar& omega)
//- Rotational transformation tensor about axis a by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Ra(const vector& a, const scalar omega)
Vertices are generated using run time compilation functionality.
File duplication avoided by placement in:
tutorials/resources/blockMesh/sloshingTank2D
tutorials/resources/blockMesh/sloshingTank3D
For example in the new tutorial case:
tutorials/incompressible/pimpleFoam/laminar/pitzDailyPulse
a cosine bell velocity pulse is specified at the inlet by directly defining the
code for it:
inlet
{
type uniformFixedValue;
uniformValue coded;
name pulse;
codeInclude
#{
#include "mathematicalConstants.H"
#};
code
#{
return vector
(
0.5*(1 - cos(constant::mathematical::twoPi*min(x/0.3, 1))),
0,
0
);
#};
}
which is then compiled automatically and linked into the running pimpleFoam
dynamically and executed to set the inlet velocity.
In the new tutorial mesh/snappyHexMesh/pipe the pipe diameter changes by a factor
of 2 but the number of cells across the pipe is specified to be constant along
the length using the new "span" refinement mode in which the number of cells
across the span is set to be at least 40:
refinementRegions
{
pipe
{
mode span;
levels ((1000 2)); // Maximum distance and maximum level
cellsAcrossSpan 40;
}
}
This operates in conjunction with the "pointCloseness" option in surfaceFeatures
which writes a surfacePointScalarField of the local span of the domain. Note
that the behaviour of this option is critically dependent on the quality of this
field and the surface may need to be re-triangulated more isotropically to
ensure the "pointCloseness" is accurate and representative of the domain and the
required mesh distribution.
A surface geometry file should be stored in
$FOAM_TUTORIALS/resources/geometry if it is used in multiple cases,
otherwise it should be stored locally to the case. This change enforces
that across all tutorials.
An adsorption condition has been added for species mass fraction. This
models a surface on which one or more species deposit at a rate
proportional to the quantity of that specie present. The property that
the rate is assumed proportional to can be chosen to be mass fraction,
mole fraction, molar concentration, or partial pressure.
Example specification in 0/CH4, 0/O2, etc...:
<patchName>
{
type adsorptionMassFraction;
property molarConcentration;
c 1e-3; // <-- Transfer coefficient
value $internalField;
}
"c" is the constant of proportionality between the property value and
the mass transfer rate. If a specie does not adsorb, this should be set
to zero, or be omitted entirely.
This condition must be supplied for all species, and corresponding
specie transfer boundary conditions must also be applied to velocity and
temperature.
Example specification in 0/U and 0/T:
<patchName>
{
type specieTransferVelocity;
value $internalField;
}
<patchName>
{
type specieTransferTemperature;
value $internalField;
}
In addition, the semi-permeable baffle conditions have been refactored
to share functionality with the new adsorption conditions. They can now
also be used with the species-transfer temperature condition, which
corrects an energy error that was present previously. The parameter
"input" has been renamed "property", consistently with the adsorption
entries listed above. Molar concentration has also been added as an
option for the property driving the transfer, so the available controls
are the same as for adsorption.
Example specification in 0/CH4, 0/O2, etc...:
<patchName>
{
type semiPermeableBaffleMassFraction;
samplePatch <neighbourPatchName>;
property molarConcentration;
c 1e-3; // <-- Transfer coefficient
value $internalField;
}
<neighbourPatchName>
{
type semiPermeableBaffleMassFraction;
samplePatch <patchName>;
property molarConcentration;
c 1e-3; // <-- Transfer coefficient
value $internalField;
}
Velocity and temperature conditions should be set in the same way as for
adsorption.
In order for the temperature condition to function satisfactorily and
not introduce unphysical variations in temperature as a result of the
linearisation to an energy boundary condition, two new base classes for
temperature conditions which explicitly set the parameters of either
gradient or mixed energy conditions have been added. The mixed condition
forms the base of the specieTransferTemperature condition.
As a result of its generalisation, the library has been renamed from
"libsemiPermeableBaffle.so" to "libspecieTransfer.so".
snappyHexMesh now generates a face-zone for the AMI-s, and createBaffles
and mergeOrSplitPoints -split are used to create the patches. Before,
snappy generated AMI patches directly, which were then converted to
AMI-s with createPatch.
This way, the AMI-s match exactly at the start of the simulation. For
more complicated cases that may be derived from this tutorial, this
could be important.
Two boundary conditions for the modelling of semi-permeable baffles have
been added. These baffles are permeable to a number of species within
the flow, and are impermeable to others. The flux of a given species is
calculated as a constant multipled by the drop in mass fraction across
the baffle.
The species mass-fraction condition requires the transfer constant and
the name of the patch on the other side of the baffle:
boundaryField
{
// ...
membraneA
{
type semiPermeableBaffleMassFraction;
samplePatch membranePipe;
c 0.1;
value uniform 0;
}
membraneB
{
type semiPermeableBaffleMassFraction;
samplePatch membraneSleeve;
c 0.1;
value uniform 1;
}
}
If the value of c is omitted, or set to zero, then the patch is
considered impermeable to the species in question. The samplePatch entry
can also be omitted in this case.
The velocity condition does not require any special input:
boundaryField
{
// ...
membraneA
{
type semiPermeableBaffleVelocity;
value uniform (0 0 0);
}
membraneB
{
type semiPermeableBaffleVelocity;
value uniform (0 0 0);
}
}
These two boundary conditions must be used in conjunction, and the
mass-fraction condition must be applied to all species in the
simulation. The calculation will fail with an error message if either is
used in isolation.
A tutorial, combustion/reactingFoam/RAS/membrane, has been added which
demonstrates this transfer process.
This work was done with support from Stefan Lipp, at BASF.
