A typical Function1 entry can be read in one of three ways; with the
parameters in the current dictionary, in a separate sub-dict, or with
the entry itself as the dictionary; e.g.,
// Current-dictionary form
<entryName> sine;
amplitude 0.1;
frequency 10;
level 0.2;
// Coeff-dictionary form
<entryName> sine;
<entryName>Coeffs
{
amplitude 0.1;
frequency 10;
level 0.2;
}
// Entry-as-dictionary form
<entryName>
{
type sine;
amplitude 0.1;
frequency 10;
level 0.2;
}
The latter two sub-dictionary forms are needed when there are multiple
Function1 entries of the same type in a dictionary. Enclosing the
parameters in a separate sub-dictionary prevents the keywords (in this
case "amplitude", "frequency" and "level") from being duplicated.
Table and constant Function1 entries are different in that they have
special formats which allow the data to be appended directly to the
entry name; e.g;
<entryName> table ((0 (1 0 0)) (1 (2 0 0)));
<entryName> constant (1 0 0);
// (constant can even have the "constant" keyword omitted)
<entryName> (1 0 0);
Table also has two optional additional controls; "outOfBounds" and
"interpolationScheme". In order for these to be written out in such a
way that the entries are not duplicated, table needs to be written out
(and therefore also read in) as one of the sub-dictionary forms. To that
effect, Table has been extended to additionally permit reading in the
three forms described previously, and to write in the coeff-dictionary
form.
// Current-dictionary form
<entryName> table;
values ((0 (1 0 0)) (1 (2 0 0)));
outOfBounds repeat;
interpolationScheme linear;
// Coeff-dictionary form
<entryName> sine;
<entryName>Coeffs
{
values ((0 (1 0 0)) (1 (2 0 0)));
outOfBounds repeat;
interpolationScheme linear;
}
// Entry-as-dictionary form
<entryName>
{
type table;
values ((0 (1 0 0)) (1 (2 0 0)));
outOfBounds repeat;
interpolationScheme linear;
}
For completeness and consistency, constant has also been modified so
that it can read in these forms. However, constant has no additional
control entries, which means writing a coeff-dictionary is unecessary,
so the output has not been changed.
// Find out if triangle inside shell with higher level
// What level does shell want to refine fc to?
//
// Note: it is not clear for what cases this additional requirement
// is beneficial but for triangulated surfaces with triangles that
// span refinement regions it introduces unnecessary refinement so
// it has been removed.
//
// This option can be reinstated under a switch if cases are
// provided which demonstrate the benefit.
/*
labelList shellLevel;
shells.findHigherLevel(ctrs, minLevelField, shellLevel);
forAll(minLevelField, i)
{
minLevelField[i] = max(minLevelField[i], shellLevel[i]);
}
*/
Resolves bug-report https://bugs.openfoam.org/view.php?id=3361
The update of mass transfer rates in the population balance system is
now done at the same time as other source terms. This benefits
synchronisation of the mass transfer rate and the source terms and
prevents the system converging to an incorrect state.
Patch contributed by VTT Technical Research Centre of Finland Ltd and
Institute of Fluid Dynamics, Helmholtz-Zentrum Dresden - Rossendorf (HZDR).
This avoids log messaged being generated by foamListTimes when optimisation
switches are set in the case controlDict, e.g.
OptimisationSwitches
{
writeNowSignal 10;
}
In order to improve stability and robustness of fluidised bed cases the
semi-implicit treatment of the particle pressure (pPrime) is now applied within
the time-step sub-cycling along with the phase differential flux update. This
allows the simulations to be performed reliably at a significantly increased
maximum Courant number (up to 5 for some cases) without introducing
chequerboarding patterns in regions of low particle phase fraction which
occurred with the previous algorithm.
The fluidisedBed tutorial has been updated to be more representative of real
bubbling bed cases and to demonstrate the new pPrime functionality.
Developed in collaboration with Timo Niemi, VTT.
These cases now check for a mesh in geometrically identical cases and
copy rather than re-generate if possible. This reduces the run-time of
the test loop by about 20 minutes.
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".
derived from solidThermo. This allows the standard heat transfer boundary
conditions, for example externalWallHeatFluxTemperature, to be used with
solidDisplacementFoam and also significantly simplifies the code.
Additionally solidDisplacementFoam and solidEquilibriumDisplacementFoam have
been updated to handle spatially varying physical properties in a conservative
manner both for the stress and heat transfer. This means that the stress field
sigma is now dynamic rather than kinematic as it was previously. For uniform
property fields the behaviour of the solvers is the same as it was before this
update.
This changes improves the update of the pPrime contribution from the particle
interaction pressure in the optional phase fraction corrector loop in
reactingTwoPhaseEulerFoam particularly for fluidized bed simulations with a hard
packing limit.
Multiphase support is also added for the optional implicit treatment of
turbulent dispersion in the phase fraction equations which will also be
applicable to particle packing when multiphase handing of kinetic theory is
added.
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.
The chemistryModel and combustionModel do not change the thermodynamics directly
and should not require non-const access to it. In order to change the
thermodynamics model argument and stored references to const the specie "active"
flags in TDAC have been changed to mutable as this is not a direct change in the
thermodynamic state but a set of switches which allow the state to change
differently during the next thermodynamics update.
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.
Reaction names are now consistently camel-cased for readability. Most
names have not been affected because the reaction rate name is a proper
noun and is therefore already capitalised (e.g., Arrhenius, Janev,
Landau, etc ...). Reactions that have been affected are as follows.
Old name New name
irreversibleinfiniteReaction irreversibleInfiniteReaction
irreversiblepowerSeriesReaction irreversiblePowerSeriesReaction
irreversiblethirdBodyArrheniusReaction irreversibleThirdBodyArrheniusReaction
nonEquilibriumReversibleinfiniteReaction nonEquilibriumReversibleInfiniteReaction
nonEquilibriumReversiblethirdBodyArrheniusReaction nonEquilibriumReversibleThirdBodyArrheniusReaction
reversibleinfiniteReaction reversibleInfiniteReaction
reversiblepowerSeriesReaction reversiblePowerSeriesReaction
reversiblethirdBodyArrheniusReaction reversibleThirdBodyArrheniusReaction
irreversiblefluxLimitedLangmuirHinshelwoodReaction irreversibleFluxLimitedLangmuirHinshelwoodReaction
irreversiblesurfaceArrheniusReaction irreversibleSurfaceArrheniusReaction
reversiblesurfaceArrheniusReaction reversibleSurfaceArrheniusReaction
Function1 has been generalised in order to provide functionality
previously provided by some near-duplicate pieces of code.
The interpolationTable and tableReader classes have been removed and
their usage cases replaced by Function1. The interfaces to Function1,
Table and TableFile has been improved for the purpose of using it
internally; i.e., without user input.
Some boundary conditions, fvOptions and function objects which
previously used interpolationTable or other low-level interpolation
classes directly have been changed to use Function1 instead. These
changes may not be backwards compatible. See header documentation for
details.
In addition, the timeVaryingUniformFixedValue boundary condition has
been removed as its functionality is duplicated entirely by
uniformFixedValuePointPatchField.
In two phases, the turbulent dispersion force is modelled for a phase
pair as follows:
F12 = D12*grad(alpha1)
Where D12 is the turbulent dispersion coefficient between phases 1 and
2. This force is calculated equivalently whichever phase is chosen to be
phase 1 because the volume fractions are related by alpha1 = 1 - alpha2.
This means that F12 == - F21; i.e., the force in one phase equals the
reaction in the other.
In multiple phases, however, a force calculated in this way is no longer
consistent between phases, because the relationship between the volume
fractions no longer applies. The following form has been chosen instead.
F12 = D12*grad(alpha1/(alpha1 + alpha2))
I.e., rather than using the gradient of a phase directly, we use the
gradient of the phase within the two-phase sub-system associated with
the pair.
This reduces to the two-phase case above, and the models available in
the literature that are explicitly formulated for multiple phases can
also be expressed in this form.
Based on a patch contributed by Institute of Fluid Dynamics, Helmholtz-Zentrum Dresden -
Rossendorf (HZDR) and VTT Technical Research Centre of Finland Ltd.
Integral evaluations have been implemented for all the ramp function1-s,
as well as the sine and square wave. Bounds handling has also been added
to the integration of table-type functions.
In addition, the sine wave "t0" paramater has been renamed "start" for
consistency with the ramp functions.
Description
Gunn (1978) correlation for fixed and fluidized beds with Re < 10^5
and continuous phase fraction between 0.35 and 1.
Reference:
\verbatim
Gunn, D. J. (1978).
Transfer of heat or mass to particles in fixed and fluidised beds.
International Journal of Heat and Mass Transfer, 21(4), 467-476.
\endverbatim
Based on code contributed by Alberto Passalacqua
Description
Calculates the thermal comfort quantities predicted mean vote (PMV) and
predicted percentage of dissatisfaction (PPD) based on DIN ISO EN 7730:2005.
Usage
\table
Property | Description | Required | Default value
clothing | The insulation value of the cloth | no | 0
metabolicRate | The metabolic rate | no | 0.8
extWork | The external work | no | 0
Trad | Radiation temperature | no | -1
relHumidity | Relative humidity of the air | no | 50
pSat | Saturation pressure of water | no | -1
tolerance | Residual control for the cloth temperature | no | 1e-5
maxClothIter | Maximum number of iterations | no | 0
meanVelocity | Use a constant mean velocity in the whole domain | no |\
false
\endtable
\table
Predicted Mean Vote (PMV) | evaluation
+ 3 | hot
+ 2 | warm
+ 1 | slightly warm
+ 0 | neutral
- 1 | slightly cool
- 2 | cool
- 3 | cold
\endtable
\verbatim
comfortAnalysis
{
type comfort;
libs ("libfieldFunctionObjects.so");
executeControl writeTime;
writeControl writeTime;
}
\endverbatim
The new tutorial case heatTransfer/buoyantSimpleFoam/comfortHotRoom is provided
to demonstrate the calculation of PMV and PPD using the comfort functionObject.
This work is based on code and case contributed by Tobias Holzmann.
