This model applies a heat source. It requires either the power, Q, or
the power per unit volume, q, to be specified.
Example usage:
heatSource
{
type heatSource;
selectionMode cellSet;
cellSet heater;
Q 1e6;
}
This model represents volumetric heat exchange with a constant ambient
temperature, using an area per unit volume, and a heat transfer
coefficient. It utilises the same heat transfer coefficient modelling as
the equivalent inter-region option.
Example usage:
heatTransfer
{
type heatTransfer;
heatTransferCoeffs
{
selectionMode cellSet;
cellSet c0;
semiImplicit no;
Ta 300;
type constant;
AoV 200;
htc 10;
}
}
There is now just one inter-region heat transfer model, and heat
transfer coefficient models are selected as sub-models. This has been
done to permit usage of the heat transfer models in other contexts.
Example usage:
interRegionHeatTransfer
{
type interRegionHeatTransfer;
interRegionHeatTransferCoeffs
{
nbrRegion other;
interpolationMethod cellVolumeWeight;
master true;
semiImplicit no;
type constant;
AoV 200;
htc 10;
}
}
pMin and pMax settings are now available in multiphaseEulerFoam in the
PIMPLE section of the system/fvOptions file. This is consistent with
other compressible solvers. The pMin setting in system/phaseProperties
is no longer read, and it's presence will result in a warning.
SLGThermo has been moved to lagrangian, which still depends on it, pending
complete removal and replacement with a more rational interface to the carrier
phase thermodynamics.
fvModels should operate primarily like a list of fvModel-s, so the index
operator of relevance is the one from its list base class. This has been
made explicit to prevent ambiguity associated with the same operator in
the dictionary base class.
These permit derivations of reynolds stress models to add source terms
into the R and epsilon equations
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
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.
A population balance suffix after the phase suffix makes determining the
phase for a given name more complex. The additional suffix is also
unnecessary as a phase can only ever belong to one population balance,
so the phase name alone uniquely idetifies the grouping.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
Field corrections are effectively explicit constraints applied to the field
after solution rather than to the equation and it significantly simplifies the
implementation to treat them as a special case of constraints. To implement
this the fvOption::correct(<field>) function has been renamed
fvOption::constrain(<field>) and uses constrainsField and constrainedFields.
