A volumetric flow rate through a tri-surface can now be obtained using
the volumetricFlowRateTriSurface preconfigured function object, using
the following entry in system/controlDict:
fuctions
{
#includeFunc "volumetricFlowRateTriSurface(name=surface.stl)"
}
Where "surface.stl" is a tri-surface file in the constant/triSurface
directory. An example of this has been added to the
incompressible/pimpleFoam/RAS/impeller tutorial case.
Note that when possible, it is preferable to use the flowRatePatch or
flowRateFaceZone functions, as these make direct use of the flux and
therefore report a value that is exactly that computed by the solver.
volumetricFlowRateTriSurface, by contrast, does interpolation of the
velocity field which introduces error.
In addition, a minor fix has been made to the underlying
surfaceFieldValue function object so that it does not need a zone/set
name when values on a searchable surface are requested.
Description
Transforms the specified velocity field into a
cylindrical polar coordinate system or back to Cartesian.
Example of function object specification to convert the velocity field U
into cylindrical polar coordinates before averaging and returning the
average to Cartesian coordinates:
\verbatim
cartesianToCylindrical
{
type cylindrical;
libs ("libfieldFunctionObjects.so");
origin (0 0 0);
axis (0 0 1);
field U;
writeControl outputTime;
writeInterval 1;
}
#includeFunc fieldAverage(cylindrical(U))
cylindricalToCartesian
{
type cylindrical;
libs ("libfieldFunctionObjects.so");
origin (0 0 0);
axis (0 0 1);
field cylindrical(U)Mean;
toCartesian true;
result UMean;
writeControl outputTime;
writeInterval 1;
}
\endverbatim
This is particularly useful for cases with rotating regions, e.g. mixer
vessels with AMI.
See tutorials/incompressible/pimpleFoam/laminar/mixerVesselAMI2D
This simplifies and standardises the handling of radiation in all solvers which
include an energy equation, all of which now support radiation via the
'radiation' fvOption which is selected in the constant/fvOption or
constant/<region>/fvOption file:
radiation
{
type radiation;
libs ("libradiationModels.so");
}
The radiation model, parameters, settings and sub-models are specified in the
'radiationProperties' file as before.
It is better to not select and instantiate a model, fvOption etc. than to create
it and set it inactive as the creation process requires reading of settings,
parameters, fields etc. with all the associated specification and storage
without being used. Also the incomplete implementation added a lot of
complexity in the low-level operation of models introducing a significant
maintenance overhead and development overhead for new models.
The convoluted separate ".*Coeffs" dictionary form of model coefficient
specification is now deprecated and replaced with the simpler sub-dictionary
form but support is provided for the deprecated form for backward comparability.
e.g.
thermophysicalProperties
{
type liquid;
useReferenceValues no;
liquid H2O;
}
rather than
filmThermoModel liquid;
liquidCoeffs
{
useReferenceValues no;
liquid H2O;
}
and
forces
{
thermocapillary;
distributionContactAngle
{
Ccf 0.085;
distribution
{
type normal;
normalDistribution
{
minValue 50;
maxValue 100;
expectation 75;
variance 100;
}
}
zeroForcePatches ();
}
}
rather than
forces
(
thermocapillary
distributionContactAngle
);
distributionContactAngleCoeffs
{
Ccf 0.085;
distribution
{
type normal;
normalDistribution
{
minValue 50;
maxValue 100;
expectation 75;
variance 100;
}
}
zeroForcePatches ();
}
All the tutorial cases containing a surface film have been updated for guidance,
e.g. tutorials/lagrangian/buoyantReactingParticleFoam/hotBoxes/constant/surfaceFilmProperties
surfaceFilmModel thermoSingleLayer;
regionName wallFilmRegion;
active true;
thermophysicalProperties
{
type liquid;
useReferenceValues no;
liquid H2O;
}
viscosity
{
model liquid;
}
deltaWet 1e-4;
hydrophilic no;
momentumTransport
{
model laminar;
Cf 0.005;
}
forces
{
thermocapillary;
distributionContactAngle
{
Ccf 0.085;
distribution
{
type normal;
normalDistribution
{
minValue 50;
maxValue 100;
expectation 75;
variance 100;
}
}
zeroForcePatches ();
}
}
injection
{
curvatureSeparation
{
definedPatchRadii
(
("(cube[0-9][0-9]_side[0-9]_to_cube[0-9][0-9]_side[0-9])" 0)
);
}
drippingInjection
{
cloudName reactingCloud1;
deltaStable 0;
particlesPerParcel 100.0;
parcelDistribution
{
type RosinRammler;
RosinRammlerDistribution
{
minValue 5e-04;
maxValue 0.0012;
d 7.5e-05;
n 0.5;
}
}
}
}
phaseChange
{
model standardPhaseChange;
Tb 373;
deltaMin 1e-8;
L 1.0;
}
upperSurfaceModels
{
heatTransfer
{
model mappedConvectiveHeatTransfer;
}
}
lowerSurfaceModels
{
heatTransfer
{
model constant;
c0 50;
}
}
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.
using Function1 and supporting all the standard Function1s including tabulated
and coded.
tutorials/multiphase/interFoam/laminar/sloshingTank3D6DoF updated to use
sixDoFMotion.
and renamed defaultSpecie as its mass fraction is derived from the sum of the
mass fractions of all other species and it need not be inert but must be present
everywhere, e.g. N2 in air/fuel combustion which can be involved in the
production of NOx.
The previous name inertSpecie in thermophysicalProperties is supported for
backward compatibility.
This tutorial now serves as an example of how to compute flow-rates
through zones defined by triangulated surfaces.
A small fix has also been added to searchableSurfaceToFaceZone to
improve robustness on ambiguous cases.
It is now possible to define coordinate systems in a central location and
selected them by name for any model requiring one, e.g. the
explicitPorositySource.
Description
Provides a centralized coordinateSystem collection.
For example with the porous region specified in \c constant/fvOptions as
\verbatim
porosity
{
type explicitPorositySource;
explicitPorositySourceCoeffs
{
selectionMode cellZone;
cellZone porousBlockage;
type DarcyForchheimer;
// D 100; // Very little blockage
// D 200; // Some blockage but steady flow
// D 500; // Slight waviness in the far wake
D 1000; // Fully shedding behavior
d ($D $D $D);
f (0 0 0);
coordinateSystem porousBlockage;
}
}
\endverbatim
the corresponding coordinate system \c porousBlockage is looked-up
automatically from the \c constant/coordinateSystems dictionary:
\verbatim
porousBlockage
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type axesRotation;
e1 (1 0 0);
e2 (0 1 0);
}
}
\endverbatim
See \c tutorials/incompressible/pisoFoam/laminar/porousBlockage
and changed to be an energy implicit correction to a temperature gradient
based heat-flux. This formulation is both energy conservative and temperature
consistent.
The wallHeatFlux functionObject has been updated to use a consistent heat-flux
from the heSolidThermo.
Fourier, eddyDiffusivity and nonUnityLewisEddyDiffusivity thermophysical
transport models now apply an implicit energy correction to a temperature
gradient based heat-flux to provide computational stability and efficiency while
converging to temperature gradient based solution. This ensures consistent heat
exchange between fluid and solid regions in CHT cases and with heat-flux
boundaries.
The Fourier and eddyDiffusivity models support single specie systems only
whereas nonUnityLewisEddyDiffusivity supports specie diffusion with independent
specification of turbulent Prandtl and Schmidt numbers, i.e. non-unity Lewis
number.
The unityLewisFourier and unityLewisEddyDiffusivity thermophysical transport
models use an implicit energy gradient based heat-flux which is optimal for
numerical stability and convergence but does not guarantee consistent heat
exchange between fluid and solid regions and heat-flux boundaries in the
presence of gradients of heat capacity. Both of these models support specie
diffusion with the restriction that the laminar and turbulent Prandtl and
Schmidt numbers are equal, i.e. unity Lewis number.
The thermophysical transport model is specified in the optional
thermophysicalTransport dictionary; if this file is not present the
unityLewisFourier model is selected for laminar and unityLewisEddyDiffusivity
for turbulent cases for backward compatibility.
The chtMultiRegionFoam tutorial cases have been updated to use the most
appropriate of the new thermophysical transport models.
This tutorial demonstrates the use of the population balance modeling
capability of multiphaseEulerFoam for the case of a vertical pipe. It
superseeds all bubbleColumnPolydisperse cases, which have been removed.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
Expanded the documentation and updated the mean free path calculation
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
Optional switches "splitPhaseFlux" and "meanFluxReference" are now provided and
can be set true in fvSolution e.g.
solvers
{
"alpha.*"
{
nAlphaCorr 1;
nAlphaSubCycles 2;
splitPhaseFlux true;
meanFluxReference true;
}
.
.
.
to reinstate the previous form of phase flux limiters in which the mean and
phase flux differences are interpolated separately and the limited correction
referenced to the mean rather than phase flux. This form of discretisation and
limiting is more aggressive than the latest version and hence less accurate but
it is hoped that the latest form of limitSum will handle the boundedness at the
upper limit reliably allowing the new more accurate limiters to be used for most
if not all multiphase simulations.
Solid thermo no longer requires a pressure field, so solid regions of
chtMultiRegionFoam cases no longer need a 0/<solidRegionName>/p file.
In order for solidThermo to continue to use heThermo and the low level
thermo classes, it now constructs a uniformGeometricScalarField for the
pressure with the value NaN. This is passed into the low-level thermo
models by heThermo. The enforces the requirement that low-level thermo
models used by solidThermo should have no pressure dependence. If an
instantiation is made with pressure dependence, the code will fail with
a floating point error.
Most fvOptions change the state of the fields and equations they are applied to
but do not change internal state so it makes more sense that the interface is
const, consistent with MeshObjects. For the few fvOptions which do maintain a
changing state the member data is now mutable.
This is useful for testing purposes in comparison with rhoPimpleFoam.
Also made a fix to the handling of multivariate convection schemes in
chtMultiRegionFoam.
The standard set of Lagrangian clouds are now selectable at run-time.
This means that a solver that supports Lagrangian modelling can now use
any type of cloud (with some restrictions). Previously, solvers were
hard-coded to use specific cloud modelling. In addition, a cloud-list
structure has been added so that solvers may select multiple clouds,
rather than just one.
The new system is controlled as follows:
- If only a single cloud is required, then the settings for the
Lagrangian modelling should be placed in a constant/cloudProperties
file.
- If multiple clouds are required, then a constant/clouds file should be
created containing a list of cloud names defined by the user. Each
named cloud then reads settings from a corresponding
constant/<cloudName>Properties file. Clouds are evolved sequentially
in the order in which they are listed in the constant/clouds file.
- If no clouds are required, then the constant/cloudProperties file and
constant/clouds file should be omitted.
The constant/cloudProperties or constant/<cloudName>Properties files are
the same as previous cloud properties files; e.g.,
constant/kinematicCloudProperties or constant/reactingCloud1Properties,
except that they now also require an additional top-level "type" entry
to select which type of cloud is to be used. The available options for
this entry are:
type cloud; // A basic cloud of solid
// particles. Includes forces,
// patch interaction, injection,
// dispersion and stochastic
// collisions. Same as the cloud
// previously used by
// rhoParticleFoam
// (uncoupledKinematicParticleFoam)
type collidingCloud; // As "cloud" but with resolved
// collision modelling. Same as the
// cloud previously used by DPMFoam
// and particleFoam
// (icoUncoupledKinematicParticleFoam)
type MPPICCloud; // As "cloud" but with MPPIC
// collision modelling. Same as the
// cloud previously used by
// MPPICFoam.
type thermoCloud; // As "cloud" but with
// thermodynamic modelling and heat
// transfer with the carrier phase.
// Same as the limestone cloud
// previously used by
// coalChemistryFoam.
type reactingCloud; // As "thermoCloud" but with phase
// change and mass transfer
// coupling with the carrier
// phase. Same as the cloud
// previously used in fireFoam.
type reactingMultiphaseCloud; // As "reactingCloud" but with
// particles that contain multiple
// phases. Same as the clouds
// previously used in
// reactingParcelFoam and
// simpleReactingParcelFoam and the
// coal cloud used in
// coalChemistryFoam.
type sprayCloud; // As "reactingCloud" but with
// additional spray-specific
// collision and breakup modelling.
// Same as the cloud previously
// used in sprayFoam and
// engineFoam.
The first three clouds are not thermally coupled, so are available in
all Lagrangian solvers. The last four are thermally coupled and require
access to the carrier thermodynamic model, so are only available in
compressible Lagrangian solvers.
This change has reduced the number of solvers necessary to provide the
same functionality; solvers that previously differed only in their
Lagrangian modelling can now be combined. The Lagrangian solvers have
therefore been consolidated with consistent naming as follows.
denseParticleFoam: Replaces DPMFoam and MPPICFoam
reactingParticleFoam: Replaces sprayFoam and coalChemistryFoam
simpleReactingParticleFoam: Replaces simpleReactingParcelFoam
buoyantReactingParticleFoam: Replaces reactingParcelFoam
fireFoam and engineFoam remain, although fireFoam is likely to be merged
into buoyantReactingParticleFoam in the future once the additional
functionality it provides is generalised.
Some additional minor functionality has also been added to certain
solvers:
- denseParticleFoam has a "cloudForceSplit" control which can be set in
system/fvOptions.PIMPLE. This provides three methods for handling the
cloud momentum coupling, each of which have different trade-off-s
regarding numerical artefacts in the velocity field. See
denseParticleFoam.C for more information, and also bug report #3385.
- reactingParticleFoam and buoyantReactingParticleFoam now support
moving mesh in order to permit sharing parts of their implementation
with engineFoam.
