The multiFieldValue function object computes a selected operation between multiple fieldValue function objects, where the operation is applied to all results of each fieldValue object.
Note that each object must generate the same number and type of results. An example input dictionary is shown below:
multiFieldValue1
{
// Mandatory entries (unmodifiable)
type multiFieldValue;
libs (fieldFunctionObjects);
// Mandatory entries (runtime modifiable)
operation subtract;
// List of fieldValue function objects as dictionaries
functions
{
region1
{
...
}
region2
{
...
}
...
regionN
{
...
}
}
// Optional (inherited) entries
...
}
Options for operation entry include:
add | sum : add all values
subtract : subtract all values from the first value
The multiRegion function object provides a wrapper that clones the supplied object for each region. This simplifies setting up identical post-processing requirements for multi-region cases. Applies the supplied function to all regions by default.
An example input dictionary is shown below:
multiRegion
{
type multiRegion;
libs (utilityFunctionObjects);
...
function
{
// Actual object specification
type fieldMinMax;
libs (fieldFunctionObjects);
fields (<field1> .. <fieldN>);
}
// Optional entries
regions (region1 region2);
}
The momentumError and div function objects can now operate on specific cellZones. The image below shows an example of the momentum error calculated for two zones of the aerofoilNACA0012 tutorial case:
Momentum error on cellZones
Using a sub-mesh reduces the computational cost of the operations. To correctly capture the error on the prescribed cellZones, a 'halo' or 'layers' of cells can be added to the original cellZones. This leads to consistent results between the full mesh and the cell zone-based predictions by taking the size of the numerical stencil into account.
Usage
Zone based calculations are enabled by the new cellZones and nlayers dictionary entries:
momentumError1
{
type momentumError;
libs (fieldFunctionObjects);
p <pName>;
U <UName>;
phi <phiName>;
cellZones (z1 z2);
nLayers 2;
}
The new ReynoldsNumber, NusseltNumber and HeatTransferCoeff cloud function objects calculate the particle Reynolds number, Nusselt number and heat transfer coefficient Lagrangian fields.
Usage
The objects can be activated in the the cloudFunctions sub-dictionary of the cloud properties file, e.g.
cloudFunctions
{
ReynoldsNumber1
{
type ReynoldsNumber;
}
NusseltNumber1
{
type NusseltNumber;
}
HeatTransferCoeff1
{
type HeatTransferCoeff;
}
}
OpenFOAM v2006 introduced a new "streaming total dynamic mode decomposition"STDMD function object to provide general DMD capabilities alongside economised and feasible CPU and memory usage. This release adds the following improvements:
Refactoring the DMD module : To help and to encourage users to implement their own DMD models, the code has been updated to offer an easier to use interface and set of class hierarchies.
Enabling the postProcess utility : STDMD can now operate both at run-time and as a post-processing tool. This allows a DMD model to be executed on existing fields via the postProcess utility after a simulation has been completed. A minimal example using the postProcess utility can be as follows (the utility reads the DMD settings from system/controlDict.functions):
<solver> -postProcess -fields '(U p)' -time '10:'
Enabling operations on patch fields : Previously, STDMD application was limited to volume/internal fields. With this release, a DMD model can now be executed in parallel on a given patch field for selected patches during an ongoing computation or during a post processing activity, e.g. for wallShearStress.
This version provides an additional filter method for distance surface, continuing the changes from OpenFOAM-v2012. As previously stated:
In addition to the original purpose of distanceSurface (to create a sampled surface at a distance from an input surface), it can also be used to sample at a zero distance from an input surface. In this mode it works much like a cell cutting method for generating surfaces.
The new proximityRegions topology filter addresses a similar problem, e.g. for the following scenario where the thin-walled pipe separates different zones topologically:
This could arise from a so-called double-dee pipe, or a sleeve with an actuator shaft:
In earlier versions the filters would either fail spectacularly by choosing the incorrect region, or become tedious to specify. To address this, the new proximityRegions topology filter combines face proximity information with topology segmentation.
This filter acts by checking the distance of the resulting faces against the original search surface and filters based on the area-weighted distance of each topologically connected region. If the area-weighted distance of a topological region is greater than the given threshold, the entire region is rejected:
The definitions of the filtering algorithms (v2106 and v2012 filters) were performed in partnership with Sven-Eric Salecker (NAVASTO GmbH, on behalf of AUDI AG) for non-trivial test geometries.
The foamToEnsight utility now supports multi-region selection and a new -allRegions option. This greatly simplifies post-processing and conversion for conjugate heat transfer (CHT) cases. As part of the improvements, a new -finite-area option has been added (similar to foamToVTK) for support of finiteArea output.
The EnSight file format is well suited to multi-region content, enabling each OpenFOAM region to correspond to a separate EnSight case file, e.g.
EnSight/
|-- bottomAir
| |-- bottomAir.case
| `-- data
|-- heater
| |-- data
| `-- heater.case
|-- leftSolid
| |-- data
| `-- leftSolid.case
|-- rightSolid
| |-- data
| `-- rightSolid.case
`-- topAir
|-- data
`-- topAir.case
This allows loading of individual or multiple regions, and permits fields such as T (temperature) that span multiple regions as well as fields such as U (velocity) that only apply to specific regions.
The separation of geometry and fields also applies to finiteArea conversions, e. g.
EnSight/
|-- finite-area
| |-- data
| `-- finite-area.case
|-- data
`-- planeTransport.case
The legacy VTK format has been updated in recent years to reflect some VTK internal changes, i.e. there are different legacy formats. This release includes an update to the VTK unstructured reader to handle both old and new legacy VTK formats, which impacts on various conversion utilities such as surfaceMeshConvert, vtkUnstructuredToFoam, and various other utilities, e.g. snappyHexMesh.
The VTK legacy output produced by OpenFOAM remains unchanged, for continuity of existing workflows. Depending the demand, output in the updated VTK legacy format may be included in the future.
The ThirdParty source packs now ship with ParaView-5.9.1 and the visualization module has been updated to support the newest VTK versions. However, there largest changes in post-processing have occurred behind the scenes.
In the long-term, we wish to deprecate the home-grown reader modules and focus on incorporating new functionality directly into the native ParaView/VTK readers.
