With the new fvModels framework it is now possible to implement complex models
and wrappers around existing complex models which can then be optionally
selected in any general solver which provides compatible fields and
thermophysical properties. This simplifies code development and maintenance by
significantly reducing complex code duplication and also provide the opportunity
of running these models in other solvers without the need for code duplication
and alteration.
The immediate advantage of this development is the replacement of the
specialised Lagrangian solvers with their general counterparts:
reactingParticleFoam -> reactingFoam
reactingParcelFoam -> reactingFoam
sprayFoam -> reactingFoam
simpleReactingParticleFoam -> reactingFoam
buoyantReactingParticleFoam -> buoyantReactingFoam
For example to run a reactingParticleFoam case in reactingFoam add the following
entries in constant/fvModels:
buoyancyForce
{
type buoyancyForce;
}
clouds
{
type clouds;
libs ("liblagrangianParcel.so");
}
which add the acceleration due to gravity needed by Lagrangian clouds and the
clouds themselves.
See the following cases for examples converted from reactingParticleFoam:
$FOAM_TUTORIALS/combustion/reactingFoam/Lagrangian
and to run a buoyantReactingParticleFoam case in buoyantReactingFoam add the
following entry constant/fvModels:
clouds
{
type clouds;
libs ("liblagrangianParcel.so");
}
to add support for Lagrangian clouds and/or
surfaceFilm
{
type surfaceFilm;
libs ("libsurfaceFilmModels.so");
}
to add support for surface film. The buoyancyForce fvModel is not required in
this case as the buoyantReactingFoam solver has built-in support for buoyancy
utilising the p_rgh formulation to provide better numerical handling for this
force for strongly buoyancy-driven flows.
See the following cases for examples converted from buoyantReactingParticleFoam:
$FOAM_TUTORIALS/combustion/buoyantReactingFoam/Lagrangian
All the tutorial cases for the redundant solvers have been updated and converted
into their new equivalents and redirection scripts replace these solvers to
provide users with prompts on which solvers have been replaced by which and
information on how to upgrade their cases.
To support this change and allow all previous Lagrangian tutorials to run as
before the special Lagrangian solver fvSolution/PIMPLE control
solvePrimaryRegion has been replaced by the more general and useful controls:
models : Enable the fvModels
thermophysics : Enable thermophysics (energy and optional composition)
flow : Enable flow (pressure/velocity system)
which also replace the fvSolution/PIMPLE control frozenFlow present in some
solvers. These three controls can be used in various combinations to allow for
example only the fvModels to be evaluated, e.g. in
$FOAM_TUTORIALS/combustion/buoyantReactingFoam/Lagrangian/rivuletPanel
PIMPLE
{
models yes;
thermophysics no;
flow no;
.
.
.
so that only the film is solved. Or during the start-up of a case it might be
beneficial to run the pressure-velocity system for a while without updating
temperature which can be achieved by switching-off thermophysics. Also the
behaviour of the previous frozenFlow switch can be reproduced by switching flow
off with the other two switches on, allowing for example reactions, temperature
and composition update without flow.
The thermo parcel now supports thermophysical property modelling. This
particle does not store phase or specie fractions so it only provides a
single phase with a uniform composition. Additional specification is
required in the cloud subModel configuration in order to select the
specie. For example:
compositionModel singlePhaseMixture;
singlePhaseMixtureCoeffs
{
phases
(
solid
{
CaCO3 1;
}
);
}
To provide more flexibility, extensibility, run-time modifiability and
consistency the handling of optional pressure limits has been moved from
pressureControl (settings in system/fvSolution) to the new limitPressure
fvConstraint (settings in system/fvConstraints).
All tutorials have been updated which provides guidance when upgrading cases but
also helpful error messages are generated for cases using the old settings
providing specific details as to how the case should be updated, e.g. for the
tutorials/compressible/rhoSimpleFoam/squareBend case which has the pressure
limit specification:
SIMPLE
{
...
pMinFactor 0.1;
pMaxFactor 2;
...
generates the error message
--> FOAM FATAL IO ERROR:
Pressure limits should now be specified in fvConstraints:
limitp
{
type limitPressure;
minFactor 0.1;
maxFactor 2;
}
file: /home/dm2/henry/OpenFOAM/OpenFOAM-dev/tutorials/compressible/rhoSimpleFoam/squareBend/system/fvSolution/SIMPLE from line 41 to line 54.
Assuming the heat required to cause the phase change is provided by the film the
energy transferred with the mass to the primary region corresponds to vapour
at the film surface temperature.
The constant heat capacity hacked thermo in surfaceFilmModels and the
corresponding transfer terms in Lagrangian have been replaced by the standard
OpenFOAM rhoThermo which provides a general handling of thermo-physical
properties, in particular non-constant heat capacity. Further rationalisation
of liquid and solid properties has also been undertaken in support of this work
to provide a completely consistent interface to sensible and absolute enthalpy.
Now for surfaceFilmModels the thermo-physical model and properties are specified
in a constant/<region>/thermophysicalProperties dictionary consistent with all
other types of continuum simulation.
This significantly rationalises, simplifies and generalises the handling of
thermo-physical properties for film simulations and is a start at doing the same
for Lagrangian.
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.
This function gives a value of one during a user-specified duration, and
zero at all other times. It is useful for defining the time range in
which an injection or ignition heat source or similar operates.
Example usage, scaling a value:
<name>
{
type scale;
scale squarePulse;
start 0;
duration 1;
value 100;
}
This function has been utilised in a number of tutorial fvOption
configurations to provide a specific window in which the fvOption is
applied. This was previously achieved by "timeStart" and "duration"
controls hard coded into the fvOptions themselves.
The injection models do not inject parcels into the film they specifically eject
parcels from the film and the name "injection" is very confusing and misleading
hence the logical rename injection -> ejection.
Originally the only supported geometry specification were triangulated surfaces,
hence the name of the directory: constant/triSurface, however now that other
surface specifications are supported and provided it is much more logical that
the directory is named accordingly: constant/geometry. All tutorial and
template cases have been updated.
Note that backward compatibility is provided such that if the constant/geometry
directory does not exist but constant/triSurface does then the geometry files
are read from there.
A dynamicMotionSolverFvMesh must now use a "motionSolver" or
"motionSolvers" entry to select the underlying motion solver. For
example, in constant/dynamicMeshDict:
dynamicFvMesh dynamicMotionSolverFvMesh;
motionSolverLibs ("librigidBodyMeshMotion.so");
motionSolver rigidBodyMotion;
...
Previously the motion solver could also be specified with the keyword
"solver", but this resulted in a name clash with rigid body solvers
which are frequently specified in the same scope. For this reason, the
"solver" and "solvers" entries have been removed.
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;
}
}
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.
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.
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.
This significant improvement is flexibility of SemiImplicitSource required a
generalisation of the source specification syntax and all tutorials have been
updated accordingly.
Description
Semi-implicit source, described using an input dictionary. The injection
rate coefficients are specified as pairs of Su-Sp coefficients, i.e.
\f[
S(x) = S_u + S_p x
\f]
where
\vartable
S(x) | net source for field 'x'
S_u | explicit source contribution
S_p | linearised implicit contribution
\endvartable
Example tabulated heat source specification for internal energy:
\verbatim
volumeMode absolute; // specific
sources
{
e
{
explicit table ((0 0) (1.5 $power));
implicit 0;
}
}
\endverbatim
Example coded heat source specification for enthalpy:
\verbatim
volumeMode absolute; // specific
sources
{
h
{
explicit
{
type coded;
name heatInjection;
code
#{
// Power amplitude
const scalar powerAmplitude = 1000;
// x is the current time
return mag(powerAmplitude*sin(x));
#};
}
implicit 0;
}
}
\endverbatim
All of the film transport equations are now formulated with respect to the film
volume fraction in the region cell layer rather than the film thickness which
ensures mass conservation of the film even as it flows over curved surfaces and
around corners. (In the previous formulation the conservation error could be as
large as 15% for a film flowing around a corner.)
The film Courant number is now formulated in terms of the film cell volumetric
flux which avoids the stabilised division by the film thickness and provides a
more reliable estimate for time-step evaluation. As a consequence the film
solution is substantially more robust even though the time-step is now
significantly higher. For film flow dominated problem the simulations now runs
10-30x faster.
The inconsistent extended PISO controls have been replaced by the standard
PIMPLE control system used in all other flow solvers, providing consistent
input, a flexible structure and easier maintenance.
The momentum corrector has been re-formulated to be consistent with the momentum
predictor so the optional PIMPLE outer-corrector loop converges which it did not
previously.
nonuniformTransformCyclic patches and corresponding fields are no longer needed
and have been removed which paves the way for a future rationalisation of the
handling of cyclic transformations in OpenFOAM to improve robustness, usability
and maintainability.
Film sources have been simplified to avoid the need for fictitious boundary
conditions, in particular mappedFixedPushedInternalValueFvPatchField which has
been removed.
Film variables previously appended with an "f" for "film" rather than "face"
have been renamed without the unnecessary and confusing "f" as they are
localised to the film region and hence already directly associated with it.
All film tutorials have been updated to test and demonstrate the developments
and improvements listed above.
Henry G. Weller
CFD Direct Ltd.
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.
This part of the name is unnecessary, as it is clear from context that
the name refers to a reaction. The selector has been made backwards
compatible so that old names will still read successfuly.
The side surfaces in this tutorial have been made symmetry planes to
match the corresponding boundaries in the film region, and the top has
had its pressure condition changed to totalPressure. The case now runs
successfully to completion.
Previously the pressure-velocity boundary condition combination on the
non-film patches was incorrect in that in regions of outflow a pressure
value was not being specified. This resulted in divergence.
Description
Reciprocal polynomial equation of state for liquids and solids
\f[
1/\rho = C_0 + C_1 T + C_2 T^2 - C_3 p - C_4 p T
\f]
This polynomial for the reciprocal of the density provides a much better fit
than the equivalent polynomial for the density and has the advantage that it
support coefficient mixing to support liquid and solid mixtures in an
efficient manner.
Usage
\table
Property | Description
C | Density polynomial coefficients
\endtable
Example of the specification of the equation of state for pure water:
\verbatim
equationOfState
{
C (0.001278 -2.1055e-06 3.9689e-09 4.3772e-13 -2.0225e-16);
}
\endverbatim
Note: This fit is based on the small amount of data which is freely
available for the range 20-65degC and 1-100bar.
This equation of state is a much better fit for water and other liquids than
perfectFluid and in general polynomials for the reciprocal of the density
converge much faster than polynomials of the density. Currently rPolynomial is
quadratic in the temperature and linear in the pressure which is sufficient for
modest ranges of pressure typically encountered in CFD but could be extended to
higher order in pressure and/temperature if necessary. The other huge advantage
in formulating the equation of state in terms of the reciprocal of the density
is that coefficient mixing is simple.
Given these advantages over the perfectFluid equation of state the libraries and
tutorial cases have all been updated to us rPolynomial rather than perfectFluid
for liquids and water in particular.
This allows much greater flexibility in the instantiation of reaction system
which may in general depend on fields other than the thermodynamic state. This
also simplifies mixture thermodynamics removing the need for the reactingMixture
and the instantiation of all the thermodynamic package combinations depending on
it.
which are now read directly from the thermophysicalProperties dictionary for
consistency with non-reacting mixture thermodynamics. The species thermo and
reactions lists can still be in separate files if convenient and included into
the thermophysicalProperties file using the standard dictionary #include.
This formalises the flexible and extensible OpenFOAM thermodynamics and reaction
format as the direct input to OpenFOAM solvers. The CHEMKIN format is still
supported by first converting to the OpenFOAM format using the chemkinToFoam
utility.
The dense drag models (WenYu, ErgunWenYu and PlessisMasliyah) have been
extended so that they can create their own void-fraction field when one
is not otherwise available.
The duplicated functionality in the drag models has been generalised and
is now utilised by multiple models.
References have been added for all models for which they could be found.
In addition, an additional drag model, SchillerNaumann, has been added.
This is of the same form as sphereDrag, and is designed for the same
scenario; sparsely distributed spherical particles. The SchillerNaumann
form is more widely referenced and should now be considered standard.
The thermo-parcel-specific force instantiation macro has been removed,
as all the force models are now possible to use with all parcel types.
Resolves bug report https://bugs.openfoam.org/view.php?id=3191
The radiation modelling library has been moved out of
thermophysicalProperties into the top-level source directory. Radiation
is a process, not a property, and belongs alongside turbulence,
combustion, etc...
The namespaces used within the radiation library have been made
consistent with the rest of the code. Selectable sub-models are in
namespaces named after their base classes. Some models have been
renamed remove the base type from the suffix, as this is unnecessary.
These renames are:
Old name: New name:
binaryAbsorptionEmission binary
cloudAbsorptionEmission cloud
constantAbsorptionEmission constant
greyMeanAbsorptionEmission greyMean/greyMeanCombustion
greyMeanSolidAbsorptionEmission greyMeanSolid
wideBandAbsorptionEmission wideBand/wideBandCombustion
cloudScatter cloud
constantScatter constant
mixtureFractionSoot mixtureFraction
Some absorption-emission models have been split into versions which do
and don't use the heat release rate. The version that does has been
given the post-fix "Combustion" and has been moved into the
combustionModels library. This removes the dependence on a registered
Qdot field, and makes the models compatible with the recent removal of
that field from the combustion solvers.
This allows coefficients of the constantAbsorptionEmission and
constantScatter to be entered as pure numbers, with the name and
dimensions set automatically, rather than having to specify them
manually.
The Qdot field has been removed from all reacting solvers, in favour of
computing on the fly whenever it is needed. It can still be generated
for post-processing purposes by means of the Qdot function object. This
change reduces code duplication and storage for all modified solvers.
The Qdot function object has been applied to a number of tutorials in
order to retain the existing output.
A fix to Qdot has also been applied for multi-phase cases.
Added headers to all reactions files to prevent warnings in paraview.
Added references for known mechanisms. Removed unused reaction and
thermophysical property files.
Now for transient simulations "Final" solver settings are required for ALL
equations providing consistency between the solution of velocity, energy,
composition and radiation properties.
However "Final" relaxation factors are no longer required for fields or
equations and if not present the standard value for the variable will be
applied. Given that relaxation factors other than 1 are rarely required for
transient runs and hence the same for all iterations including the final one
this approach provide simpler input while still providing the flexibility to
specify a different value for the final iteration if required. For steady cases
it is usual to execute just 1 outer iteration per time-step for which the
standard relaxation factors are appropriate, and if more than one iteration is
executed it is common to use the same factors for both. In the unlikely event
of requiring different relaxation factors for the final iteration this is still
possible to specify via the now optional "Final" specification.
coneInjection has been extended to include the functionality of
coneNozzleInjection, and the latter has been removed.
Some parameters have changed names. The "positionAxis" entry from
coneInjection has been removed in preferance of coneNozzleInjection's
single "position" and "direction" entries. This means that only one
injection site is possible per model (dictionary substitutions mean that
only minimal additions are required to add further injection sites with
the same parameters). The name of the velocity magnitude has been
standardised as "Umag" and "innerDiameter" and "outerDiamater" have been
renamed "dInner" and "dOuter" for consistency with the inner and outer
spray angles.
Velocity magnitude and diameters are no longer read when they are not
required.
The randomisation has been altered so that the injections generate a
uniform distribution on an cross section normal to the direction of
injection. Previously there was an unexplained bias towards the
centreline.
An example specification with a full list of parameters is shown below.
injectionModels
{
model1
{
type coneInjection;
// Times
SOI 0;
duration 1;
// Quantities
massTotal 0; // <-- not used with these settings
parcelBasisType fixed;
parcelsPerSecond 1000000;
flowRateProfile constant 1;
nParticle 1;
// Sizes
sizeDistribution
{
type fixedValue;
fixedValueDistribution
{
value 0.0025;
}
}
// Geometry
positions (-0.15 -0.1 0);
directions (1 0 0);
thetaInner 0;
thetaOuter 45;
// - Inject at a point
injectionMethod point;
// - Or, inject over a disc:
/*
injectionMethod disc;
dInner 0;
dOuter 0.05;
*/
// Velocity
// - Inject with constant velocity
flowType constantVelocity;
Umag 1;
// - Or, inject with flow rate and discharge coefficient
// This also requires massTotal, dInner and dOuter
/*
flowType flowRateAndDischarge;
Cd 0.9;
*/
// - Or, inject at a pressure
/*
flowType pressureDrivenVelocity;
Pinj 10e5;
*/
}
model2
{
// The same as model1, but at a different position
$model1;
position (-0.15 0.1 0);
}
}
Changed liquid thermo from sensibleEnthalpy to sensibleInternalEnergy in
tutorials. It is generally more convergent and stable to solve for internal
energy if the fluid is incompressible or weakly compressible.
With the -noFields option the mesh is subset but the fields are not changed.
This is useful when the field fields have been created to correspond to the mesh
after the mesh subset.
