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.
The standard set of Lagrangian clouds are now selectable at run-time.
This means that a solver that supports Lagrangian modelling can now use
any type of cloud (with some restrictions). Previously, solvers were
hard-coded to use specific cloud modelling. In addition, a cloud-list
structure has been added so that solvers may select multiple clouds,
rather than just one.
The new system is controlled as follows:
- If only a single cloud is required, then the settings for the
Lagrangian modelling should be placed in a constant/cloudProperties
file.
- If multiple clouds are required, then a constant/clouds file should be
created containing a list of cloud names defined by the user. Each
named cloud then reads settings from a corresponding
constant/<cloudName>Properties file. Clouds are evolved sequentially
in the order in which they are listed in the constant/clouds file.
- If no clouds are required, then the constant/cloudProperties file and
constant/clouds file should be omitted.
The constant/cloudProperties or constant/<cloudName>Properties files are
the same as previous cloud properties files; e.g.,
constant/kinematicCloudProperties or constant/reactingCloud1Properties,
except that they now also require an additional top-level "type" entry
to select which type of cloud is to be used. The available options for
this entry are:
type cloud; // A basic cloud of solid
// particles. Includes forces,
// patch interaction, injection,
// dispersion and stochastic
// collisions. Same as the cloud
// previously used by
// rhoParticleFoam
// (uncoupledKinematicParticleFoam)
type collidingCloud; // As "cloud" but with resolved
// collision modelling. Same as the
// cloud previously used by DPMFoam
// and particleFoam
// (icoUncoupledKinematicParticleFoam)
type MPPICCloud; // As "cloud" but with MPPIC
// collision modelling. Same as the
// cloud previously used by
// MPPICFoam.
type thermoCloud; // As "cloud" but with
// thermodynamic modelling and heat
// transfer with the carrier phase.
// Same as the limestone cloud
// previously used by
// coalChemistryFoam.
type reactingCloud; // As "thermoCloud" but with phase
// change and mass transfer
// coupling with the carrier
// phase. Same as the cloud
// previously used in fireFoam.
type reactingMultiphaseCloud; // As "reactingCloud" but with
// particles that contain multiple
// phases. Same as the clouds
// previously used in
// reactingParcelFoam and
// simpleReactingParcelFoam and the
// coal cloud used in
// coalChemistryFoam.
type sprayCloud; // As "reactingCloud" but with
// additional spray-specific
// collision and breakup modelling.
// Same as the cloud previously
// used in sprayFoam and
// engineFoam.
The first three clouds are not thermally coupled, so are available in
all Lagrangian solvers. The last four are thermally coupled and require
access to the carrier thermodynamic model, so are only available in
compressible Lagrangian solvers.
This change has reduced the number of solvers necessary to provide the
same functionality; solvers that previously differed only in their
Lagrangian modelling can now be combined. The Lagrangian solvers have
therefore been consolidated with consistent naming as follows.
denseParticleFoam: Replaces DPMFoam and MPPICFoam
reactingParticleFoam: Replaces sprayFoam and coalChemistryFoam
simpleReactingParticleFoam: Replaces simpleReactingParcelFoam
buoyantReactingParticleFoam: Replaces reactingParcelFoam
fireFoam and engineFoam remain, although fireFoam is likely to be merged
into buoyantReactingParticleFoam in the future once the additional
functionality it provides is generalised.
Some additional minor functionality has also been added to certain
solvers:
- denseParticleFoam has a "cloudForceSplit" control which can be set in
system/fvOptions.PIMPLE. This provides three methods for handling the
cloud momentum coupling, each of which have different trade-off-s
regarding numerical artefacts in the velocity field. See
denseParticleFoam.C for more information, and also bug report #3385.
- reactingParticleFoam and buoyantReactingParticleFoam now support
moving mesh in order to permit sharing parts of their implementation
with engineFoam.
The reactingtTwoPhaseEulerFoam solver has been replaced by the more general
multiphaseEulerFoam solver which supports two-phase and multiphase systems
containing fluid and stationary phases, compressible or incompressible, with
heat and mass transfer, reactions, size distribution and all the usual phase
interaction and transfer models.
All reactingtTwoPhaseEulerFoam tutorials have been ported to multiphaseEulerFoam
to demonstrate two-phase capability with a wide range of phase and
phase-interaction models.
When running with two-phases the optional referencePhase entry in
phaseProperties can be used to specify which phase fraction should not be
solved, providing compatibility with reactingtTwoPhaseEulerFoam, see
tutorials/multiphase/multiphaseEulerFoam/RAS/fluidisedBed
tutorials/multiphase/multiphaseEulerFoam/laminar/bubbleColumn
for examples.
Description
Stops the run when the specified clock time in second has been reached
and optionally write results before stopping.
The following actions are supported:
- noWriteNow
- writeNow
- nextWrite (default)
Examples of function object specification:
\verbatim
stop
{
type stopAtClockTime;
libs ("libutilityFunctionObjects.so");
stopTime 10;
action writeNow;
}
\endverbatim
will stop the run at the next write after the file "stop" is created in the
case directory.
Usage
\table
Property | Description | Required | Default value
type | type name: stopAtClockTime | yes |
stopTime | Maximum elapsed time [s] | yes |
action | Action executed | no | nextWrite
\endtable
By default the case stops following the next write but stopping immediately with
or without writing are also options.
The stopAtFile functionObject derived from stopAt stops the run when a file
predefined file is created in the case directory:
Description
Stops the run when the specified file is created in the case directory.
The default name of the trigger file is \c $FOAM_CASE/<name> where \c
<name> is the name of the functionObject entry and the default action is \c
nextWrite.
Currently the following action types are supported:
- noWriteNow
- writeNow
- nextWrite
Examples of function object specification:
\verbatim
stop
{
type stopAtFile;
libs ("libutilityFunctionObjects.so");
}
\endverbatim
will stop the run at the next write after the file "stop" is created in the
case directory.
\verbatim
stop
{
type stopAtFile;
libs ("libutilityFunctionObjects.so");
file "$FOAM_CASE/stop";
action writeNow;
}
\endverbatim
will write the fields and stop the run when the file "stop" is created in
the case directory.
Usage
\table
Property | Description | Required | Default value
type | type name: stopAtFile | yes |
file | Trigger file path name | no | $FOAM_CASE/<name>
action | Action executed | no | nextWrite
\endtable
providing the shear-stress term in the momentum equation for incompressible and
compressible Newtonian, non-Newtonian and visco-elastic laminar flow as well as
Reynolds averaged and large-eddy simulation of turbulent flow.
The general deviatoric shear-stress term provided by the MomentumTransportModels
library is named divDevTau for compressible flow and divDevSigma (sigma =
tau/rho) for incompressible flow, the spherical part of the shear-stress is
assumed to be either included in the pressure or handled separately. The
corresponding stress function sigma is also provided which in the case of
Reynolds stress closure returns the effective Reynolds stress (including the
laminar contribution) or for other Reynolds averaged or large-eddy turbulence
closures returns the modelled Reynolds stress or sub-grid stress respectively.
For visco-elastic flow the sigma function returns the effective total stress
including the visco-elastic and Newtonian contributions.
For thermal flow the heat-flux generated by thermal diffusion is now handled by
the separate ThermophysicalTransportModels library allowing independent run-time
selection of the heat-flux model.
During the development of the MomentumTransportModels library significant effort
has been put into rationalising the components and supporting libraries,
removing redundant code, updating names to provide a more logical, consistent
and extensible interface and aid further development and maintenance. All
solvers and tutorials have been updated correspondingly and backward
compatibility of the input dictionaries provided.
Henry G. Weller
CFD Direct Ltd.
This provides an extensible and run-time selectable framework to support complex
energy and specie transport models, in particular multi-component diffusion.
Currently only the Fourier for laminar and eddyDiffusivity for RAS and LES
turbulent flows are provided but the interface is general and the set of models
will be expanded in the near future.
Following the generalisation of the TurbulenceModels library to support
non-Newtonian laminar flow including visco-elasticity and extensible to other
form of non-Newtonian behaviour the name TurbulenceModels is misleading and does
not properly represent how general the OpenFOAM solvers now are. The
TurbulenceModels now provides an interface to momentum transport modelling in
general and the plan is to rename it MomentumTransportModels and in preparation
for this the turbulenceProperties dictionary has been renamed momentumTransport
to properly reflect its new more general purpose.
The old turbulenceProperties name is supported for backward-compatibility.
Additional flexibility for handling of field arguments has been extended
to dictionary lists of field settings, as well as word lists of field
names. This means that the following syntax is now supported:
postProcess -func "fieldAverage(p, U { prime2Mean on; }, T)"
postProcess -func "fieldAverage(fields=(p U { prime2Mean on; } T))"
Rather than specifying the controls per field it is simpler to use a single set
of controls for all the fields in the list and use separate instances of the
fieldAverage functionObject for different control sets:
Example of function object specification setting all the optional parameters:
fieldAverage1
{
type fieldAverage;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
restartOnRestart false;
restartOnOutput false;
periodicRestart false;
restartPeriod 0.002;
base time;
window 10.0;
windowName w1;
mean yes;
prime2Mean yes;
fields (U p);
}
This allows for a simple specification with the optional prime2Mean entry using
#includeFunc fieldAverage(U, p, prime2Mean = yes)
or if the prime2Mean is not needed just
#includeFunc fieldAverage(U, p)
The mean, prime2Mean and base now have default values:
{
mean on; // (default = on)
prime2Mean on; // (default = off)
base time; // time or iteration (default = time)
window 200; // optional averaging window
windowName w1; // optional window name (default = "")
}
so for the majority of cases for which these defaults are appropriate the
fieldAverage functionObject can now be specified in the functions entry in
controlDict thus:
functions
{
fieldAverage1
{
#includeEtc "caseDicts/postProcessing/fields/fieldAverage.cfg"
fields
(
U.air
U.water
alpha.air
p
);
}
}
also utilising the new fieldAverage.cfg file.
For cases in which these defaults are not appropriate, e.g. the prime2Mean is
also required the optional entries can be specified within sub-dictionaries for
each field, e.g.
fieldAverage1
{
#includeEtc "caseDicts/postProcessing/fields/fieldAverage.cfg"
fields
(
U
{
prime2Mean yes;
}
p
{
prime2Mean yes;
}
);
}
The total enthalpy is calculated as
Ha = ha + K
where
ha is absolute enthalpy
K is the kinetic energy: 1/2*magSqr(U)
The total enthalpy or a particular phase can be calculated by specifying the
optional "phase" name, e.g.
#includeFunc totalEnthalpy(phase = liquid)
This is particularly useful for multiphase simulations for which integrating the
density weighted phase properties also requires the phase fraction to be
including in the weighting.
A single weight field can be specified as before:
weightField rho;
or a list specified by:
weightFields (alpha.water rho.water);
