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).
This is a modified Arrhenius reaction rate where the reaction rate is
multiplied by a surface area per unit volume.
The reaction rate is given by:
k = (A * T^beta * exp(-Ta/T))*a
Where a is the surface area per unit volume, the name of which is
specified by the user. This enables, for example, the reaction rate to
depend on the surface area concentration of catalyst particles.
Patch contributed by VTT Technical Research Centre of Finland Ltd and
Institute of Fluid Dynamics, Helmholtz-Zentrum Dresden - Rossendorf (HZDR).
Surface area per unit volume is now available in the diameter models.
Storing the diameter and/or surface area per unit volume fields can now
be activated for any model by means of "storeD" and "storeA"
switches. If the underlying model already stores the field then the
switch is ignored.
Based on a patch contributed by VTT Technical Research Centre of Finland Ltd and
Institute of Fluid Dynamics, Helmholtz-Zentrum Dresden - Rossendorf (HZDR).
A clause preventing solution of the density equation has been removed
from reactingParcelFoam and chtMultiRegionFoam, so that they are nore
consistent with other compressible solvers. In general, the density
equation is solved before the pimple loop is entered to make sure that
the flux and the density derivative are consistent during the first
pimple iteration.
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
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
Description
A wrapper class to reverse any ramp function such that the result starts
from 1 decreasing to 0 from \c start over the \c duration and remaining at 0
thereafter.
Usage for scaling a vector:
\verbatim
<entryName>
{
scale
{
type reverseRamp;
ramp linearRamp;
start 0;
duration 10;
}
value
{
type sine;
frequency 10;
amplitude 1;
scale (1 0.1 0);
level (10 1 0);
}
}
\endverbatim
Based on code contributed by SeongMo Yeon
See https://bugs.openfoam.org/view.php?id=3358
Provides access to properties of the model and current state for complex and
time-dependent restraints.
Patch contributed by SeongMo Yeon
Resolves contribution https://bugs.openfoam.org/view.php?id=3345#c10787
Changed the interpolation of HbyA from
fvc::flux(rho*HbyA)
to
fvc::interpolate(rho)*fvc::flux(HbyA)
for consistency with the latest compressible p-U algorithm in rhoPimpleFoam.
For most cases this change does not affect the results but test on highly
compressible, transonic and supersonic cases have shown a small but clear
benefit in the new form.
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.
Cached temporary objects are now registered from the moment of
construction. This means it is possible to use them before they go out
of scope. Non-cached temporaries are not registered, as before.
The check for the existence of requested cached objects is now done
after function object evaluation. This means that caching can be done on
fields generated by the function objects themselves without generating
warning messages.
The above, however, means that if an object isn't successfully cached
and it's lookup in a function fails, then the warning will not be
generated before the lookup raises an error. This could make diagnosing
the reason for such a failure more difficult. To remedy this the content
of the warning (i.e., the list of objects that are available for
caching) has been added to the lookup error message if the looked up
name is on the caching list. The same level of logged information is
therefore retained in the event of caching and lookup failures.
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.
By default most functionObjects now execute and write at the start-time except
those that perform averaging (fieldAverage, dsmcFields) which cannot be executed
until the end of the first time-step. There is also a new optional
functionObject dictionary entry "executeAtStart" which defaults to true but can
be set false if the execution and results of the functionObject are not required
or appropriate at the start-time.
A result of this change is that time logs of forces, sampling etc. now include a
values for time 0.
Description
Calculates the natural logarithm of the specified scalar field.
Performs \f$ln(max(x, a))\f$ where \f$x\f$ is the field and \f$a\f$ an
optional clip to handle 0 or negative \f$x\f$. Dimension checking can
optionally be suspended for this operation if \f$x\f$ is dimensioned.
Example of function object specification:
\verbatim
log1
{
type log;
libs ("libfieldFunctionObjects.so");
field p;
clip 1e-3;
checkDimensions no;
}
\endverbatim
or using \c postProcess
\verbatim
postProcess -func 'log(p, clip=1e-3, checkDimensions=no)'
\endverbatim
Usage
\table
Property | Description | Required | Default value
type | Type name: log | yes |
clip | Clip value | no |
checkDimensions | Dimension checking switch | no |
\endtable
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".
Mass transfer for a pair is now no longer available at the top level.
The solver should never need to know mass transfer rates individually;
the dmdts method (which returns all mass transfers simultaneously)
should be sufficient.
In addition the construction of zero-valued fields and addition of
fields into lists and tables within the phase system has been
simplified and code duplication removed.
The density time-derivative terms should always appear in the pressure
equation except when the phase is isochoric (i.e., the equation of state
is constant density) and the phase is pure (as species fraction changes
can also generate changes in density, even for an isochoric equation of
state). The logic in the pressure equations of reactingTwoPhaseEulerFoam
and reactingMultphaseEulerFoam has been changed to fulfil this
requirement.
This has resolved a mass-conservation issue with the
waterAndIsopropanolEvaporation case, which uses a multi-component liquid
with a constant-density equation of state.
A number of fixes have been made to the mass transfer implementations in
the phase system hierarchy in order to improve conservation of energy,
and other properties.
From an implementation perspective, each phase system that defines mass
transfer now has also to implement all property transfers that occur as
a result. The base classes no longer generate the transfers
automatically; it is not in general possible to correctly calculate the
property transfer terms from a single accumulated mass transfer rate.
To facilitate this additional burden on the derived layers, a number of
addDmdt? and addDmidt? methods have been added which compute and add
these transfers into the governing equations in a generic manner. In the
case of simple explicit mass transfers, a mass-transferring system need
only pass a table of the transfer rates to these functions in order to
generate the appropriate transfer terms.
The difference between the addDmdt? and addDmidt? methods is that the
former takes a table of bulk transfers across the interfaces, whilst the
latter takes a table-of-tables of individual species transfers.
Updates to PopulationBalancePhaseSystem and
ThermalPhaseChangePhaseSystem were provided by Timo Niemi, and Juho
Peltola, VTT.
Blended models are now constructed with the same phase order as the
corresponding pair stored by the phase system. This should ultimately
prevent some of the sign comparisons that are currently necessary when
applying models.
