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.
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).
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 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.
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
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.
Mass transfer rates now have a more comprehensive naming convention.
"dmdt" means a bulk/mixture transfer, whilst "dmidt" is for a
specie-specific transfer. "dmdt" implies a transfer into a phase, whilst
"dmdtf" means a transfer across an interface. Tables or lists of
transfers are denoted by pluralising the name with the suffix "s"; e.g.,
"dmdtfs". All registered mass transfer rate fields have names which
include the name of the sub-model or phase system which generated them.
The phaseTransfer models have been changed so that the mixture and the
specie-specific mass transfers are independent. This simplifies the
naming convention required for registering the resulting mass transfers
and reduces the amount of logic necessary in the phase system.
The inheritance pattern of the alphat wall functions has been altered so
that the code and parameters relating to phase change are reused, and so
that the base (the Jayatilleke wall function) more closely resembles the
library implementation. This should make it easier to remove it when the
library function is generalised enough to use it directly.
The phaseSystem::zero*Field construction functions have been removed as
their behaviour regarding registration was not clear, and in most
instances of their usage the GeometriField<...>::New methods are
similarly convenient.
This change extends phaseTransferModel and PhaseTransferPhaseSystem to
allow non-uniform specie transfer between phases.
A reactionDriven phaseTransfer model is added which represents change of
selected species from one phase to another due to a reaction occurring
within one of the phases.
Following the change, the reactionDriven nucleation models and the
phaseChange drift models in populationBalanceModel have been updated to
use the new functionality in PhaseTransferPhaseSystem. The
PopulationBalancePhaseSystem has been simplified significantly as a
result.
The functionality is demonstrated by a tutorial case simulating the
vapour phase synthesis of titania by titanium tetrachloride oxidation
where both nucleation and surface reactions models are active at the
same time.
Patch contributed by VTT Technical Research Centre of Finland Ltd and
Institute of Fluid Dynamics, Helmholtz-Zentrum Dresden - Rossendorf (HZDR).
to enable the calculation of the residence time for a fluid; mainly used in HVAC
analysis. E.g. residence time of air inside a ventilated room, see the new
tutorial roomResidenceTime.
Contributed by Tobias Holzmann
Rather than defining patches for all external block faces to provide name and
type use the defaultPatch entry to collect undefined faces into a single named
and typed patch, e.g.
defaultPatch
{
name walls;
type wall;
}
Description
Time-dependent external force restraint using Function1.
Usage
Example applying a constant force to the floatingObject:
restraints
{
force
{
type externalForce;
body floatingObject;
location (0 0 0);
force (100 0 0);
}
}
Based on code contributed by SeongMo Yeon
Resolves contribution request https://bugs.openfoam.org/view.php?id=3358
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.
All multi-specie solvers function on the assumption that the
mass-diffusivities of the different species are the same. A consequence
of this is that the diffusivities of energy and mass must be the same,
otherwise mass diffusivity results in unphysical temperature
fluctuations. This change enforces this requirement across all
multi-species solvers.
For the same reason, the turbulent Schmidt number has been removed from
the multi-component phase model in reactingEulerFoam. In order to obey
physical constraints this Schmidt number had to be exactly the same as
the Prandtl number. This condition is now enforced by the solver, rather
than relying on the input being correct.
Interface composition models are now specified in
constant/phaseProperties like so:
interfaceComposition.gas
(
(gas and water)
{
// ...
}
(gas and oil)
{
// ...
}
);
interfaceComposition.water
(
(water and gas)
{
// ...
}
// ...
);
// ...
I.e., the models associated with diffusive transfer within a phase
"<phase>" are specified in the list "interfaceComposition.<phase>".
Within the list, models are specified in unordered phase pairs
corresponding to the interface.
This replaces a system where models were specified in a single
interfaceComposition list, with the ordered pair entry "(<phase1> in
<phase2>)" meaning transfer within phase1 at the interface with phase2.
This ordered pair syntax is otherwise used for distinguishing between
continuous and dispersed phases. This dual meaning was considered
counter-intuitive. The new entries also more closely resemble the
associated two-resistance heat and mass transfer model specifications.
There are now many types of mass transfer, so massTransfer is now too
generic a term for what these models do. These models generate a
diffusivity which when multiplied by a concentration difference results
in mass transfer, hence the new name.
This change is not backwards compatible. Cases running the interface
composition system will need "massTransfer" entries renamed to
"diffusiveMassTransfer".
The new optional entry alphap is the as phase fraction below which bubble
generated turbulence is included. The default is 1 for backward compatibility.
The purpose of this limiter is to avoid spurious turbulence generation at and
around the interface where bubbles are not present.
If the functionObject requires an object list rather than a field list the
non-named arguments are now inserted into the object list, for example
functions
{
#includeFunc writeObjects(kEpsilon:G)
}
which is equivalent to
functions
{
#includeFunc writeObjects(objects = (kEpsilon:G))
}
For example the generation term in the k-epsilon turbulence kEpsilon:G is a
temporary field that is specifically named and registered so that it can be
looked-up be the wall-function boundary conditions and requires slightly
different handling compared to normal temporary fields which are not registered.
The tutorials/incompressible/simpleFoam/pitzDaily case now demostrates this
functionality with the addition of
cacheTemporaryObjects
(
kEpsilon:G
);
functions
{
#includeFunc writeObjects(objects = (kEpsilon:G))
}
in controlDict which caches kEpsilon:G and writes it at every write time.
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.
