When an fvModel source introduces fluid into a simulation it should also
create a corresponding source term for all properties transported into
the domain by that injection. The source is, effectively, an alternative
form of inlet boundary, on which all transported properties need an
inlet value specified.
These values are now specified in the property field files. The
following is an example of a 0/U file in which the velocity of fluid
introduced by a fvModel source called "injection1" is set to a fixed
value of (-1 0 0):
dimensions [0 1 -1 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
#includeEtc "caseDicts/setConstraintTypes"
wall
{
type noSlip;
}
atmosphere
{
type pressureInletOutletVelocity;
value $internalField;
}
}
// *** NEW ***
sources
{
injection1
{
type uniformFixedValue;
uniformValue (-1 0 0);
}
}
And the following entry in the 0/k file specifies the turbulent kinetic
energy introduced as a fraction of the mean flow kinetic energy:
sources
{
injection1
{
type turbulentIntensityKineticEnergy;
intensity 0.05;
}
}
The specification is directly analogous to boundary conditions. The
conditions are run-time selectable and can be concisely implemented.
They can access each other and be inter-dependent (e.g., the above,
where turbulent kinetic energy depends on velocity). The syntax keeps
field data localised and makes the source model (e.g., massSource,
volumeSource, ...) specification independent from what other models and
fields are present in the simulation. The 'fieldValues' entry previously
required by source models is now no longer required.
If source values need specifying and no source condition has been
supplied in the relevant field file then an error will be generated.
This error is similar to that generated for missing boundary conditions.
This replaces the behaviour where sources such as these would introduce
a value of zero, either silently or with a warning. This is now
considered unacceptable. Zero might be a tolerable default for certain
fields (U, k), but is wholly inappropriate for others (T, epsilon, rho).
This change additionally makes it possible to inject fluid into a
multicomponent solver with a specified temperature. Previously, it was
not possible to do this as there was no means of evaluating the energy
of fluid with the injected composition.
Mixture classes (e.g., pureMixtrure, coefficientMulticomponentMixture),
now have no fvMesh or volScalarField dependence. They operate on
primitive values only. All the fvMesh-dependent functionality has been
moved into the base thermodynamic classes. The 'composition()' access
function has been removed from multi-component thermo models. Functions
that were once provided by composition base classes such as
basicSpecieMixture and basicCombustionMixture are now implemented
directly in the relevant multi-component thermo base class.
The timeName() function simply returns the dimensionedScalar::name() which holds
the user-time name of the current time and now that timeName() is no longer
virtual the dimensionedScalar::name() can be called directly. The timeName()
function implementation is maintained for backward-compatibility.
The basic thermophysical properties are now considered fundamental and complex
models like kineticTheoryModel using these names for some other purpose must
disambiguate using typedName to prepend the model name to the field name.
This change standardises, rationalises and simplifies the specification of
fvSchemes and boundary conditions.
thermo:rho will also be renamed rho in a subsequent commit to complete this
rationalisation.
to handle isotropic and anisotropic is a consistent, general and extensible
manner, replacing the horrible hacks which were in solidThermo.
This is entirely consistent with thermophysicalTransportModel for fluids and
provides the q() and divq() for the solid energy conservation equations. The
transport model and properties are specified in the optional
thermophysicalTransport dictionary, the default model being isotropic if this
dictionary file is not present, thus providing complete backward-compatibility
for the common isotropic cases.
Anisotropic thermal conductivity is now handled in a much more general manner by
the anisotropic model:
Class
Foam::solidThermophysicalTransportModels::anisotropic
Description
Solid thermophysical transport model for anisotropic thermal conductivity
The anisotropic thermal conductivity field is evaluated from the solid
material anisotropic kappa specified in the physicalProperties dictionary
transformed into the global coordinate system using default
coordinate system and optionally additional coordinate systems specified
per-zone in the thermophysicalProperties dictionary.
Usage
Example of the anisotropic thermal conductivity specification in
thermophysicalProperties with two zone-based coordinate systems in
addition to the default:
\verbatim
model anisotropic;
// Default coordinate system
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type cylindrical;
e3 (1 0 0);
}
}
// Optional zone coordinate systems
zones
{
coil1
{
type cartesian;
origin (0.1 0.2 0.7);
coordinateRotation
{
type cylindrical;
e3 (0.5 0.866 0);
}
}
coil2
{
type cartesian;
origin (0.4 0.5 1);
coordinateRotation
{
type cylindrical;
e3 (0.866 0.5 0);
}
}
}
\endverbatim
This development required substantial rationalisation of solidThermo,
coordinateSystems and updates to the solid solver module, solidDisplacementFoam,
the wallHeatFlux functionObject, thermalBaffle and all coupled thermal boundary
conditions.
Field settings can now be specified within
createNonConformalCouplesDict. This allows for patchType overrides; for
example to create a jump condition over the coupling.
An alternate syntax has been added to facilitate this. If patch fields
do not need overriding then the old syntax can be used where patches
that are to be coupled are specified as a pair of names; e.g.:
fields yes;
nonConformalCouples
{
fan
{
patches (fan0 fan1);
transform none;
}
}
If patch fields do need overriding, then instead of the "patches" entry,
separate "owner" and "neighbour" sub-dictionaries should be used. These
can both contain a "patchFields" section detailing the boundary
conditions that apply to the newly created patches:
fields yes;
nonConformalCouples
{
fan
{
owner
{
patch fan0;
patchFields
{
p
{
type fanPressureJump;
patchType nonConformalCyclic;
jump uniform 0;
value uniform 0;
jumpTable polynomial 1((100 0));
}
}
}
neighbour
{
patch fan1;
patchFields
{
$../../owner/patchFields;
}
}
transform none;
}
}
In this example, only the pressure boundary condition is overridden on
the newly created non-conformal cyclic. All other fields will have the
basic constraint type (i.e., nonConformalCyclic) applied.
Now that Cp and Cv are cached it is more convenient and consistent and slightly
more efficient to cache thermal conductivity kappa rather than thermal
diffusivity alpha which is not a fundamental property, the appropriate form
depending on the energy solved for. kappa is converted into the appropriate
thermal diffusivity for the energy form solved for by dividing by the
corresponding cached heat capacity when required, which is efficient.
to provide a single consistent code and user interface to the specification of
physical properties in both single-phase and multi-phase solvers. This redesign
simplifies usage and reduces code duplication in run-time selectable solver
options such as 'functionObjects' and 'fvModels'.
* physicalProperties
Single abstract base-class for all fluid and solid physical property classes.
Physical properties for a single fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties' dictionary.
Physical properties for a phase fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties.<phase>' dictionary.
This replaces the previous inconsistent naming convention of
'transportProperties' for incompressible solvers and
'thermophysicalProperties' for compressible solvers.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the
'physicalProperties' dictionary does not exist.
* phaseProperties
All multi-phase solvers (VoF and Euler-Euler) now read the list of phases and
interfacial models and coefficients from the
'constant/<region>/phaseProperties' dictionary.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the 'phaseProperties'
dictionary does not exist. For incompressible VoF solvers the
'transportProperties' is automatically upgraded to 'phaseProperties' and the
two 'physicalProperties.<phase>' dictionary for the phase properties.
* viscosity
Abstract base-class (interface) for all fluids.
Having a single interface for the viscosity of all types of fluids facilitated
a substantial simplification of the 'momentumTransport' library, avoiding the
need for a layer of templating and providing total consistency between
incompressible/compressible and single-phase/multi-phase laminar, RAS and LES
momentum transport models. This allows the generalised Newtonian viscosity
models to be used in the same form within laminar as well as RAS and LES
momentum transport closures in any solver. Strain-rate dependent viscosity
modelling is particularly useful with low-Reynolds number turbulence closures
for non-Newtonian fluids where the effect of bulk shear near the walls on the
viscosity is a dominant effect. Within this framework it would also be
possible to implement generalised Newtonian models dependent on turbulent as
well as mean strain-rate if suitable model formulations are available.
* visosityModel
Run-time selectable Newtonian viscosity model for incompressible fluids
providing the 'viscosity' interface for 'momentumTransport' models.
Currently a 'constant' Newtonian viscosity model is provided but the structure
supports more complex functions of time, space and fields registered to the
region database.
Strain-rate dependent non-Newtonian viscosity models have been removed from
this level and handled in a more general way within the 'momentumTransport'
library, see section 'viscosity' above.
The 'constant' viscosity model is selected in the 'physicalProperties'
dictionary by
viscosityModel constant;
which is equivalent to the previous entry in the 'transportProperties'
dictionary
transportModel Newtonian;
but backward-compatibility is provided for both the keyword and model
type.
* thermophysicalModels
To avoid propagating the unnecessary constructors from 'dictionary' into the
new 'physicalProperties' abstract base-class this entire structure has been
removed from the 'thermophysicalModels' library. The only use for this
constructor was in 'thermalBaffle' which now reads the 'physicalProperties'
dictionary from the baffle region directory which is far simpler and more
consistent and significantly reduces the amount of constructor code in the
'thermophysicalModels' library.
* compressibleInterFoam
The creation of the 'viscosity' interface for the 'momentumTransport' models
allows the complex 'twoPhaseMixtureThermo' derived from 'rhoThermo' to be
replaced with the much simpler 'compressibleTwoPhaseMixture' derived from the
'viscosity' interface, avoiding the myriad of unused thermodynamic functions
required by 'rhoThermo' to be defined for the mixture.
Same for 'compressibleMultiphaseMixture' in 'compressibleMultiphaseInterFoam'.
This is a significant improvement in code and input consistency, simplifying
maintenance and further development as well as enhancing usability.
Henry G. Weller
CFD Direct Ltd.
for chemFoam, fireFoam, buoyantReactingFoam, reactingFoam, chtMultiRegionFoam,
buoyantReactingParticleFoam, reactingParticleFoam, simpleReactingParticleFoam
If the combination of chemistry model and solver selected in chemistryProperties
is not already compiled and present in the standard libraries for the selected
thermophysical properties the chemistry package will be constructed and compiled
automatically using the standard dynamicCode system provided in OpenFOAM.
The chemistry package is constructed automatically from the
etc/codeTemplates/dynamicCode/basicChemistryModel.* files, if these files do not
exist the standard chemistry lookup error message is generated as before.
As with all other dynamicCode options in OpenFOAM (codeStream,
codedFunctionObject etc.) dynamic compilation of the chemistry package is only
enabled if allowSystemOperations is set true.
psiReactionThermo- and rhoReactionThermo-s now derive from an additional
fluidReactionThermo class and are included on a corresponding run-time
selection table.
This means all multi-specie solvers can now be used with either
compressibility/psi- or density/rho-based thermodynamic models, in the
same way that non-reacting solvers can.
rhoReactingFoam has been removed, as it is no longer necessary now that
reactingFoam can operate with density-based thermodynamics.
rhoReactingBuoyantFoam has also been renamed buoyantReactingFoam to
reflect the fact that it is no longer a variant specific to
density-based thermodynamics; it can now operate with
compressibility-based thermodynamic models as well.
The change is fully backwards compatible. All cases should continue to
run without modification, apart from the fact that a different solver
might need to be called.
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".
The pressure provided to the patch and cellSet property evaluation functions is
always that stored by the thermodynamics package as is the composition which is
provided internally; given that these functions are used in boundary conditions
to estimate changes in heat flux corresponding to changes in temperature only
there is no need for another pressure to be provided. In order that the
pressure and composition treatment are consistent and to maintain that during
future rationalisation of the handling of composition it makes sense to remove
this unnecessary pressure argument.
Registration occurs when the temporary field is transferred to a non-temporary
field via a constructor or if explicitly transferred to the database via the
regIOobject "store" methods.
This allows single, multi-phase and VoF compressible simulations to be performed
with the accurate thermophysical property functions for liquids provided by the
liquidProperty classes. e.g. in the
multiphase/compressibleInterFoam/laminar/depthCharge2D tutorial water can now be
specified by
thermoType
{
type heRhoThermo;
mixture pureMixture;
properties liquid;
energy sensibleInternalEnergy;
}
mixture
{
H2O;
}
as an alternative to the previous less accurate representation defined by
thermoType
{
type heRhoThermo;
mixture pureMixture;
transport const;
thermo hConst;
equationOfState perfectFluid;
specie specie;
energy sensibleInternalEnergy;
}
mixture
{
specie
{
molWeight 18.0;
}
equationOfState
{
R 3000;
rho0 1027;
}
thermodynamics
{
Cp 4195;
Hf 0;
}
transport
{
mu 3.645e-4;
Pr 2.289;
}
}
However the increase in accuracy of the new simpler and more convenient
specification and representation comes at a cost: the NSRDS functions used by
the liquidProperties classes are relatively expensive to evaluate and the
depthCharge2D case takes ~14% longer to run.
These new names are more consistent and logical because:
primitiveField():
primitiveFieldRef():
Provides low-level access to the Field<Type> (primitive field)
without dimension or mesh-consistency checking. This should only be
used in the low-level functions where dimensional consistency is
ensured by careful programming and computational efficiency is
paramount.
internalField():
internalFieldRef():
Provides access to the DimensionedField<Type, GeoMesh> of values on
the internal mesh-type for which the GeometricField is defined and
supports dimension and checking and mesh-consistency checking.
When the GeometricBoundaryField template class was originally written it
was a separate class in the Foam namespace rather than a sub-class of
GeometricField as it is now. Without loss of clarity and simplifying
code which access the boundary field of GeometricFields it is better
that GeometricBoundaryField be renamed Boundary for consistency with the
new naming convention for the type of the dimensioned internal field:
Internal, see commit a25a449c9e
This is a very simple text substitution change which can be applied to
any code which compiles with the OpenFOAM-dev libraries.
