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
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.
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.
to provide a single consistent code and user interface to the specification of
physical properties in both single-phase and multi-phase solvers. This redesign
simplifies usage and reduces code duplication in run-time selectable solver
options such as 'functionObjects' and 'fvModels'.
* physicalProperties
Single abstract base-class for all fluid and solid physical property classes.
Physical properties for a single fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties' dictionary.
Physical properties for a phase fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties.<phase>' dictionary.
This replaces the previous inconsistent naming convention of
'transportProperties' for incompressible solvers and
'thermophysicalProperties' for compressible solvers.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the
'physicalProperties' dictionary does not exist.
* phaseProperties
All multi-phase solvers (VoF and Euler-Euler) now read the list of phases and
interfacial models and coefficients from the
'constant/<region>/phaseProperties' dictionary.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the 'phaseProperties'
dictionary does not exist. For incompressible VoF solvers the
'transportProperties' is automatically upgraded to 'phaseProperties' and the
two 'physicalProperties.<phase>' dictionary for the phase properties.
* viscosity
Abstract base-class (interface) for all fluids.
Having a single interface for the viscosity of all types of fluids facilitated
a substantial simplification of the 'momentumTransport' library, avoiding the
need for a layer of templating and providing total consistency between
incompressible/compressible and single-phase/multi-phase laminar, RAS and LES
momentum transport models. This allows the generalised Newtonian viscosity
models to be used in the same form within laminar as well as RAS and LES
momentum transport closures in any solver. Strain-rate dependent viscosity
modelling is particularly useful with low-Reynolds number turbulence closures
for non-Newtonian fluids where the effect of bulk shear near the walls on the
viscosity is a dominant effect. Within this framework it would also be
possible to implement generalised Newtonian models dependent on turbulent as
well as mean strain-rate if suitable model formulations are available.
* visosityModel
Run-time selectable Newtonian viscosity model for incompressible fluids
providing the 'viscosity' interface for 'momentumTransport' models.
Currently a 'constant' Newtonian viscosity model is provided but the structure
supports more complex functions of time, space and fields registered to the
region database.
Strain-rate dependent non-Newtonian viscosity models have been removed from
this level and handled in a more general way within the 'momentumTransport'
library, see section 'viscosity' above.
The 'constant' viscosity model is selected in the 'physicalProperties'
dictionary by
viscosityModel constant;
which is equivalent to the previous entry in the 'transportProperties'
dictionary
transportModel Newtonian;
but backward-compatibility is provided for both the keyword and model
type.
* thermophysicalModels
To avoid propagating the unnecessary constructors from 'dictionary' into the
new 'physicalProperties' abstract base-class this entire structure has been
removed from the 'thermophysicalModels' library. The only use for this
constructor was in 'thermalBaffle' which now reads the 'physicalProperties'
dictionary from the baffle region directory which is far simpler and more
consistent and significantly reduces the amount of constructor code in the
'thermophysicalModels' library.
* compressibleInterFoam
The creation of the 'viscosity' interface for the 'momentumTransport' models
allows the complex 'twoPhaseMixtureThermo' derived from 'rhoThermo' to be
replaced with the much simpler 'compressibleTwoPhaseMixture' derived from the
'viscosity' interface, avoiding the myriad of unused thermodynamic functions
required by 'rhoThermo' to be defined for the mixture.
Same for 'compressibleMultiphaseMixture' in 'compressibleMultiphaseInterFoam'.
This is a significant improvement in code and input consistency, simplifying
maintenance and further development as well as enhancing usability.
Henry G. Weller
CFD Direct Ltd.
Packaged function objects can now be deployed equally effectively by
(a) using a locally edited copy of the configuration file, or by
(b) passing parameters as arguments to the global configuration file.
For example, to post-process the pressure field "p" at a single location
"(1 2 3)", the user could first copy the "probes" packaged function
object file to their system directory by calling "foamGet probes". They
could then edit the file to contain the following entries:
points ((1 2 3));
field p;
The function object can then be executed by the postProcess application:
postProcess -func probes
Or it can be called at run-time, by including from within the functions
section of the system/controlDict file:
#includeFunc probes
Alternatively, the field and points parameters could be passed as
arguments either to the postProcess application by calling:
postProcess -func "probes(points=((1 2 3)), p)"
Or by using the #includeFunc directive:
#includeFunc probes(points=((1 2 3)), p)
In both cases, mandatory parameters that must be either edited or
provided as arguments are denoted in the configuration files with
angle-brackets, e.g.:
points (<points>);
Many of the packaged function objects have been split up to make them
more specific to a particular use-case. For example, the "surfaces"
function has been split up into separate functions for each surface
type; "cutPlaneSurface", "isoSurface", and "patchSurface". This
splitting means that the packaged functions now only contain one set of
relevant parameters so, unlike previously, they now work effectively
with their parameters passed as arguments. To ensure correct usage, all
case-dependent parameters are considered mandatory.
For example, the "streamlines" packaged function object has been split
into specific versions; "streamlinesSphere", "streamlinesLine",
"streamlinesPatch" and "streamlinesPoints". The name ending denotes the
seeding method. So, the following command creates ten streamlines with
starting points randomly seeded within a sphere with a specified centre
and radius:
postProcess -func "streamlinesSphere(nPoints=10, centre=(0 0 0), radius=1)"
The equivalent #includeFunc approach would be:
#includeFunc streamlinesSphere(nPoints=10, centre=(0 0 0), radius=1)
When passing parameters as arguments, error messages report accurately
which mandatory parameters are missing and provide instructions to
correct the format of the input. For example, if "postProcess -func
graphUniform" is called, then the code prints the following error message:
--> FOAM FATAL IO ERROR:
Essential value for keyword 'start' not set
Essential value for keyword 'end' not set
Essential value for keyword 'nPoints' not set
Essential value for keyword 'fields' not set
In function entry:
graphUniform
In command:
postProcess -func graphUniform
The function entry should be:
graphUniform(start = <point>, end = <point>, nPoints = <number>, fields = (<fieldNames>))
file: controlDict/functions/graphUniform from line 15 to line 25.
As always, a full list of all packaged function objects can be obtained
by running "postProcess -list", and a description of each function can
be obtained by calling "foamInfo <functionName>". An example case has
been added at "test/postProcessing/channel" which executes almost all
packaged function objects using both postProcess and #includeFunc. This
serves both as an example of syntax and as a unit test for maintenance.
The fieldsExpression function has been generalised to work with a
general operator. Existing functions "add" and "subtract" have been made
to use this system, and two new operations, "multiply" and "divide",
have been added.
The functions can now handle multiple types in both input and output. A
multiply (outer product) operation on two vectors and a scalar will
result in a tensor. If the operation chain is not supported (e.g.,
division by a vector) then a warning will be generated.
In addition, a "uniform" function has been added, which will create a
uniform geometric field of a given type with specified dimensions and
calculated boundary conditions. This is mostly useful for testing
purposes and for conveniently creating simple input fields for the
operation functions described above. The function can be called by
postProcess as follows:
postProcess -func "uniform(fieldType=volScalarField, name=length, dimensions=[m], value=2)"
A number of changes have been made to the surfaceFieldValue and
volFieldValue function objects to improve their usability and
performance, and to extend them so that similar duplicate functionality
elsewhere in OpenFOAM can be removed.
Weighted operations have been removed. Weighting for averages and sums
is now triggered simply by the existence of the "weightField" or
"weightFields" entry. Multiple weight fields are now supported in both
functions.
The distinction between oriented and non-oriented fields has been
removed from surfaceFieldValue. There is now just a single list of
fields which are operated on. Instead of oriented fields, an
"orientedSum" operation has been added, which should be used for
flowRate calculations and other similar operations on fluxes.
Operations minMag and maxMag have been added to both functions, to
calculate the minimum and maximum field magnitudes respectively. The min
and max operations are performed component-wise, as was the case
previously.
In volFieldValue, minMag and maxMag (and min and mag operations when
applied to scalar fields) will report the location, cell and processor
of the maximum or minimum value. There is also a "writeLocation" option
which if set will write this location information into the output file.
The fieldMinMax function has been made obsolete by this change, and has
therefore been removed.
surfaceFieldValue now operates in parallel without accumulating the
entire surface on the master processor for calculation of the operation.
Collecting the entire surface on the master processor is now only done
if the surface itself is to be written out.
The FOAM file format has not changed from version 2.0 in many years and so there
is no longer a need for the 'version' entry in the FoamFile header to be
required and to reduce unnecessary clutter it is now optional, defaulting to the
current file format 2.0.
The writer class has been renamed setWriter in order to clarify its
usage. The coordSet and setWriter classes have been moved into the
sampling library, as this fits their usage.
The MomentumTransportModels library now builds of a standard set of
phase-incompressible and phase-compressible models. This replaces most
solver-specific builds of these models.
This has been made possible by the addition of a new
"dynamicTransportModel" interface, from which all transport classes used
by the momentum transport models now derive. For the purpose of
disambiguation, the old "transportModel" has also been renamed
"kinematicTransportModel".
This change has been made in order to create a consistent definition of
phase-incompressible and phase-compressible MomentumTransportModels,
which can then be looked up by functionObjects, fvModels, and similar.
Some solvers still build specific momentum transport models, but these
are now in addition to the standard set. The solver does not build all
the models it uses.
There are also corresponding centralised builds of phase dependent
ThermophysicalTransportModels.
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.
Usage
\table
Property | Description | Required | Default value
type | Type name: forces | yes |
log | Write force data to standard output | no | no
patches | Patches included in the forces calculation | yes |
p | Pressure field name | no | p
U | Velocity field name | no | U
rho | Density field name (see below) | no | rho
phase | Phase name for phase-fraction | no |
CofR | Centre of rotation (see below) | no |
directForceDensity | Force density supplied directly (see below)|no|no
fD | Name of force density field (see below) | no | fD
\endtable
with the optional 'phase' entry the corresponding phase-fraction is used to
filter the surfaces forces for that phase.
setTimeStep is now compatible with a 'writeControl adjustableRunTime;'
setting in the systemControlDict. If 'adjustableRunTime' is selected
then the time-step values set by this function object will not be
exactly as specified, but write intervals will be matched exactly.
All function object time adjustment is now done during the execute
methods, so the specific setTimeStep hooks have been removed.
All function objects now re-read as a result of run-time modifications
to the system/controlDict.
Function objects that write log files (via the logFiles class) will now
generate a new postProcessing/<funcName>/<time> directory as a result of
either restart or run-time modification. Log files will therefore never
be overwritten by restart or run-time modification, except for when a
case is restarted at the same time as a previous execution (e.g.,
repeated runs at the start time).
If the surfaceFieldValue function object is used to compute an
area-normal average or integral of a vector quantity, the result will
now be correctly written out as a scalar.
Previously surfaceFieldValue was limited to writing the same type as the
input field. A vector area-normal average or integral therefore had to
be written out as a vector. This was done by setting the x component to
the result, and the y and z components to zero. This was considered to
be counter-intuitive.
A volumetric flow rate through a tri-surface can now be obtained using
the volumetricFlowRateTriSurface preconfigured function object, using
the following entry in system/controlDict:
fuctions
{
#includeFunc "volumetricFlowRateTriSurface(name=surface.stl)"
}
Where "surface.stl" is a tri-surface file in the constant/triSurface
directory. An example of this has been added to the
incompressible/pimpleFoam/RAS/impeller tutorial case.
Note that when possible, it is preferable to use the flowRatePatch or
flowRateFaceZone functions, as these make direct use of the flux and
therefore report a value that is exactly that computed by the solver.
volumetricFlowRateTriSurface, by contrast, does interpolation of the
velocity field which introduces error.
In addition, a minor fix has been made to the underlying
surfaceFieldValue function object so that it does not need a zone/set
name when values on a searchable surface are requested.
Description
Transforms the specified velocity field into a
cylindrical polar coordinate system or back to Cartesian.
Example of function object specification to convert the velocity field U
into cylindrical polar coordinates before averaging and returning the
average to Cartesian coordinates:
\verbatim
cartesianToCylindrical
{
type cylindrical;
libs ("libfieldFunctionObjects.so");
origin (0 0 0);
axis (0 0 1);
field U;
writeControl outputTime;
writeInterval 1;
}
#includeFunc fieldAverage(cylindrical(U))
cylindricalToCartesian
{
type cylindrical;
libs ("libfieldFunctionObjects.so");
origin (0 0 0);
axis (0 0 1);
field cylindrical(U)Mean;
toCartesian true;
result UMean;
writeControl outputTime;
writeInterval 1;
}
\endverbatim
This is particularly useful for cases with rotating regions, e.g. mixer
vessels with AMI.
See tutorials/incompressible/pimpleFoam/laminar/mixerVesselAMI2D
Description
Updates the writeInterval as a Function1 of time.
Examples of function object specification:
\verbatim
setWriteInterval
{
type setWriteInterval;
libs ("libutilityFunctionObjects.so");
writeInterval table
(
(0 0.005)
(0.1 0.005)
(0.1001 0.01)
(0.2 0.01)
(0.2001 0.02)
);
}
\endverbatim
will cause results to be written every 0.005s between 0 and 0.1s, every
0.01s between 0.1 and 0.2s and every 0.02s thereafter.
Following functionality added:
- support of dimensional inputs
- run time selection mechanism of HTC model (kappaEff, ReynoldsAnalogy)
- kappaEff has now two options for calculating HTC (with/without characteristic length)
- Reynolds Analogy estimation for HTC
- integrated HTC replaced with an average log output
Description
Calculates and writes the estimated heat transfer coefficient at wall
patches as the volScalarField field.
All wall patches are included by default; to restrict the calculation to
certain patches, use the optional 'patches' entry.
The models are selected run time by model entry. For detailed description
look at the header file for specific model under
wallHeatTransferCoeffModels.
Example of function object specification:
\verbatim
kappaEff1
{
type wallHeatTransferCoeff;
libs ("libfieldFunctionObjects.so");
model kappaEff;
...
region fluid;
patches (".*Wall");
rho 1.225;
Cp 1005;
Prl 0.707;
Prt 0.9;
}
\endverbatim
\verbatim
kappaEff2
{
type wallHeatTransferCoeff;
libs ("libfieldFunctionObjects.so");
model kappaEff;
...
region fluid;
patches (".*Wall");
rho 1.225;
Cp 1005;
Prl 0.707;
Prt 0.9;
Lchar 0.001;
}
\endverbatim
\verbatim
ReynoldsAnalogy1
{
type wallHeatTransferCoeff;
libs ("libfieldFunctionObjects.so");
model ReynoldsAnalogy;
...
region fluid;
patches (".*Wall");
rho 1.225;
Cp 1005;
Uref 1.0;
}
\endverbatim
Note
Writing field 'wallHeatTransferCoeff' is done by default, but it can be
overridden by defining an empty \c objects list. For details see
writeLocalObjects.
The streamLines function object now writes out "age" by default. This is
calculated as the total integration time from the starting point of the
streamline. This value can be negative if tracking is performed in the
reverse direction. Writing "age" can be deactivated by means of a
"writeAge no;" entry in the function object specification.
The wallHeatFlux field is now intensive with units [W/m^2]
and the minimum, maximum, patch integrated Q [W] and patch average q [W-m^2]
are written in postProcessing/wallHeatFlux/<time>/wallHeatFlux.dat
This avoids attempting to write temporary fields before they have been created.
The executeAtStart can be set to 'yes' in the writeObjects dictionary or the
functions
{
#includeFunc writeObjects(executeAtStart = yes, <field1>, <field2>...)
}
This is a slight modification of the previous commit. All cached
temporary fields are now written to disk with the name enclosed by
"tmp<...>". This still allows for automatically constructed
field names to be read by paraFoam and other post-processing tools. It
also creates a consistent convention for naming all cached temporary
fields that are written to disk.
for example
cacheTemporaryObjects
(
"((1|((1|(1|A(U)))-H(1)))-(1|A(U)))"
);
functions
{
#includeFunc writeObjects(regExp=off, "((1|((1|(1|A(U)))-H(1)))-(1|A(U)))")
}
writes the temporary field with the name
"expr((1|((1|(1|A(U)))-H(1)))-(1|A(U)))" so that it can be read by paraFoam and
other post-processing tools.
such that div(q()) = divq(...)
and div(j()) = divj(...)
to unsure consistency between the reported heat (e.g. by the wallHeatFlux
functionObject) and mass fluxes and those used in the energy and specie
mass-fraction equations.
and changed to be an energy implicit correction to a temperature gradient
based heat-flux. This formulation is both energy conservative and temperature
consistent.
The wallHeatFlux functionObject has been updated to use a consistent heat-flux
from the heSolidThermo.
