This change formalises the usage of the "log" keyword in function
objects. By default, logging to stdout is activated when running
"postProcess" or "<solver> -postProcess", and deactivated when a
function is being executed as part of a run.
This behaviour can now be overridden in the function object dictionary
when operating in either mode.
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.
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.
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
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.
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
The yPlus function object can now take a "phase" keyword which defines
the name of the phase for which to write yPlus. For example, to write
yPlus for a phase named "liquid", the following entry can be used:
yPlus1
{
type yPlus;
libs ("libfieldFunctionObjects.so");
phase liquid;
}
Note that this will only be necessary in Euler-Euler type simulations
where the phases have separate turbulence models. For VoF, the phase
name will not be required.
Patch contributed by Juho Peltola, VTT.
Currently these deleted function declarations are still in the private section
of the class declarations but will be moved by hand to the public section over
time as this is too complex to automate reliably.
Replaced all uses of complex Xfer class with C++11 "move" constructors and
assignment operators. Removed the now redundant Xfer class.
This substantial changes improves consistency between OpenFOAM and the C++11 STL
containers and algorithms, reduces memory allocation and copy overhead when
returning containers from functions and simplifies maintenance of the core
libraries significantly.
This is like the scalarTrasport function except that the transported
scalar is confined to a single phase of a multiphase simulation. In
addition to the usual specification for the scalarTransport function
(i.e., a field, schemes and solution parameters), the user needs to
specify the phase-flux or a pressure field which can be used to generate
it.
Example usage for interFoam:
phaseScalarTransport1
{
type phaseScalarTransport;
libs ("libsolverFunctionObjects.so");
field s.water;
p p_rgh;
}
Example usage for reactingTwoPhaseEulerFoam:
phaseScalarTransport1
{
type phaseScalarTransport;
libs ("libsolverFunctionObjects.so");
field s.water;
alphaPhi alphaRhoPhi.water;
rho thermo:rho.water;
}
The function will write out both the per-unit-phase field that is solved
for (s.water in the above examples) and also the mixture-total field
(alphaS.water), which is often more convenient for post-processing.
The dynamic code functionality has been generalised so that the names of
the code entries in the specifying dictionary can be set by the caller.
This means that functions which utilise dynamic code but use different
entry names (e.g., codedFunctionObject uses codeExecute, codeEnd,
etc..., instead of code) now function correctly. The differently named
entries now form part of the library hash, and re-building triggers
appropriately as they are modified.
Registration occurs when the temporary field is transferred to a non-temporary
field via a constructor or if explicitly transferred to the database via the
regIOobject "store" methods.
This object calculates a field of the age of fluid in the domain; i.e.,
the time taken for a fluid particle to travel to a location from an
inlet. It outputs a field, named age, with dimensions of time, and
requires a solver and a div(phi,age) scheme to be specified. A number of
corrections for the solution procedure can be set, as well as the name
of the flux and density fields.
Example specification:
age1
{
type age;
libs ("libfieldFunctionObjects.so");
nCorr 10;
phi phi;
rho rho;
}
Example usage:
postProcess -func age -fields "(phi)" -latestTime
This work was supported by Robert Secor and Lori Holmes, at 3M
Now for transient simulations "Final" solver settings are required for ALL
equations providing consistency between the solution of velocity, energy,
composition and radiation properties.
However "Final" relaxation factors are no longer required for fields or
equations and if not present the standard value for the variable will be
applied. Given that relaxation factors other than 1 are rarely required for
transient runs and hence the same for all iterations including the final one
this approach provide simpler input while still providing the flexibility to
specify a different value for the final iteration if required. For steady cases
it is usual to execute just 1 outer iteration per time-step for which the
standard relaxation factors are appropriate, and if more than one iteration is
executed it is common to use the same factors for both. In the unlikely event
of requiring different relaxation factors for the final iteration this is still
possible to specify via the now optional "Final" specification.
By default the prefix is no longer added to the field names but the previous
behaviour can be reproduced by setting the optional "prefix" entry to "on" or
"yes".
