This required standardisation of the mapping between the class and selection
names of the solid transport models:
constIso -> constIsoSolid
exponential -> exponentialSolid
polynomial -> polynomialSolid
To simplify maintenance and further development of chemistry solution the
standardChemistryModel and TDACChemistryModel have been merged into the single
chemistryModel class. Now the TDAC mechanism reduction and tabulation
components can be individually selected or set to "none" or the corresponding
entries in the chemistryProperties dictionary omitted to switch them off thus
reproducing the behaviour of the standardChemistryModel.
For example the following chemistryProperties includes TDAC:
#includeEtc "caseDicts/solvers/chemistry/TDAC/chemistryProperties.cfg"
chemistryType
{
solver ode;
}
chemistry on;
initialChemicalTimeStep 1e-7;
odeCoeffs
{
solver seulex;
absTol 1e-8;
relTol 1e-1;
}
reduction
{
tolerance 1e-4;
}
tabulation
{
tolerance 3e-3;
}
#include "reactionsGRI"
and to run without TDAC the following is sufficient:
chemistryType
{
solver ode;
}
chemistry on;
initialChemicalTimeStep 1e-7;
odeCoeffs
{
solver seulex;
absTol 1e-8;
relTol 1e-1;
}
#include "reactionsGRI"
or the "reduction" and "tabulation" entries can be disabled explicitly:
#includeEtc "caseDicts/solvers/chemistry/TDAC/chemistryProperties.cfg"
chemistryType
{
solver ode;
}
chemistry on;
initialChemicalTimeStep 1e-7;
odeCoeffs
{
solver seulex;
absTol 1e-8;
relTol 1e-1;
}
reduction
{
method none;
tolerance 1e-4;
}
tabulation
{
method none;
tolerance 3e-3;
}
#include "reactionsGRI"
Most tabulation and reduction specific code in TDACChemistryModel has been moved
into the appropriate tabulation and reduction classes and the "none" methods of
each simplified so that they can be instantiated without any user input. This
allows the "none" tabulation and reduction methods to be selected automatically
when the "tabulation" or "reduction" entries are not present in the
chemistryProperties dictionary so that the TDACChemistryModel can be run in the
same manner as the standardChemistryModel when tabulation and reduction are not
required.
This is the first step towards merging TDACChemistryModel with standardChemistryModel.
The draught rate determines the percentage of affected people by an airflow
caused due to room ventilation or buoyancy effects (cold windows). The draught
rate calculation is valid for room temperatures between 20 and 26 degrees
Celsius and airspeed less than 0.5 m/s. This quantity is used widely for
quantifying offices, auditoriums, or similar rooms in which persons are working.
Patch contributed by Tobias Holzmann
Both AMIMethod and mapNearestMethod are run-time selectable using the standard
OpenFOAM constructor tables, they do not need a separate enumeration-based
selection method which requires duplicate constructors and a lot of other
clutter.
The rotatedBoxToCell topoSet source can now be specified by providing
the geometry of a non-rotated box and how it should be rotated. For
example, in system/topoSetDict:
actions
(
{
name c1;
type cellSet;
action new;
source rotatedBoxToCell;
box (0.4 0.4 -100) (0.6 0.6 100);
centre (0.4 0.4 0);
n1 (1 0 0);
n2 (1 1 0);
}
);
This selects cells in a box rotated from (1 0 0) to (1 1 0) (i.e., 45
degrees around the z-axis), with width and depth of 0.2, height of 200,
and with a bottom left corner at (0.4 0.4 -100).
The origin, i, j, k, specification is still available, and will be used
if the keyword "box" is not present. The equivalent input to the above
in this form is as follows:
actions
(
{
name c1;
type cellSet;
action new;
source rotatedBoxToCell;
origin (0.4 0.4 -100);
i (0.141421 0.141421 0);
j (-0.141421 0.141421 0);
k (0 0 200);
}
);
Stokes-type waves (i.e., Airy, Stokes2 and Stokes5) now support
specification in terms of wave period, as well as length. The following
specifications are therefore equivalent:
Stokes2
{
length 300; // <-- Wave length specified
amplitude 2.5;
phase 0;
angle 0;
depth 50;
}
Stokes2
{
period 15.643; // <-- Wave period specified
amplitude 2.5;
phase 0;
angle 0;
depth 50;
}
Note that the period is that of the wave in a reference frame with zero
mean flow. Specifying a doppler shifted period is not yet supported.
Exactly one of period or length must be specified. If both, or neither,
are provided then an error will be generated.
Corrections have also been made to the calculation of the celerity of
Stokes2 and Stokes5 waves.
It is now possible to use waveVelocity and waveAlpha boundary conditions
in cases in which the waves generate localised flow reversals along the
boundary. This means waves can be speficied at arbitrary directions and
with zero mean flow. Previously and integral approach, similar to
flowRateOutlet, was used, which was only correct when the direction of
wave propagation was aligned with the boundary normal.
This improvement has been achieved by reformulating the waveVelocity and
waveAlpha boundary conditions in terms of a new fixedValueInletOutlet
boundary condition type. This condition enforces a fixed value in all
cases except that of advection terms in the presence of outflow. In this
configuration a gradient condition is applied that will relax towards
the desired fixed value.
The wavePressure boundary condition has been removed, as it is no longer
necessary or advisable to locally switch between velocity and pressure
formulations along a wave boundary. Wave boundaries should now have the
general fixedFluxPressure or fixedFluxExtrapolatedPressure conditions
applied to the pressure field.
Two new tutorial cases have been created to demonstrate the new
functionality. The multiphase/interFoam/laminar/wave3D case demonstrates
wave generation with zero mean flow and at arbitrary angles to the
boundaries, and incompressible/pimpleFoam/RAS/waveSubSurface
demonstrates usage for sub-surface problems.
This fixes a crash that occured when the field that the fvModel applies
to does not exist at the point of the fvModel's construction. This is
the case for function objects that solve equations, e.g., the
scalarTransport or age functions, as the relevant fields are constructed
on demand at the point of the functions' execution. Sources and
constraints now work correctly for these sorts of equations.
used to check the existence of and open an object file, read and check the
header without constructing the object.
'typeIOobject' operates in an equivalent and consistent manner to 'regIOobject'
but the type information is provided by the template argument rather than via
virtual functions for which the derived object would need to be constructed,
which is the case for 'regIOobject'.
'typeIOobject' replaces the previous separate functions 'typeHeaderOk' and
'typeFilePath' with a single consistent interface.
Robustness improvements have been made to the "behind" system which
prevents the tracking system from hanging. Addition protections have
also been added to prevent division by subnormal numbers and associated
floating point errors.
Warning messages for faces which cannot be tetrahedralised with purely
positive tetrahedra are now generated once per face at each timestep.
This means they do not fill the log if the same face is encountered
multiple times, and they are also are visible throughout a log.
now all path functions in 'IOobject' are either templated on the type or require a
'globalFile' argument to specify if the type is case global e.g. 'IOdictionary' or
decomposed in parallel, e.g. almost everything else.
The 'global()' and 'globalFile()' virtual functions are now in 'regIOobject'
abstract base-class and overridden as required by derived classes. The path
functions using 'global()' and 'globalFile()' to differentiate between global
and processor local objects are now also in 'regIOobject' rather than 'IOobject'
to ensure the path returned is absolutely consistent with the type.
Unfortunately there is still potential for unexpected IO behaviour inconsistent
with the global/local nature of the type due to the 'fileOperation' classes
searching the processor directory for case global objects before searching the
case directory. This approach appears to be a work-around for incomplete
integration with and rationalisation of 'IOobject' but with the changes above it
is no longer necessary. Unfortunately this "up" searching is baked-in at a low
level and mixed-up with various complex ways to pick the processor directory
name out of the object path and will take some unravelling but this work will
undertaken as time allows.
for local and global files so that the reading and writing of local files to
processor directories and global files to the case directory are consistent.
to the <case>/<time>/uniform or <case>/<processor>/<time>/uniform directory.
Adding a new form of IOdictionary for this purpose allows significant
simplification and rationalisation of regIOobject::writeObject, removing the
need for explicit treatment of different file types.
