v2112: New and improved post-processing
TOP
The new propellerInfo function object derives propeller performance and wake field properties. Performance is controlled by the executeControl settings, where the output is written both to the log file and to disk, including:
- Thrust coefficient, Kt
- Torque coefficient, 10*Kq
- Advance coefficient, J
- Open water efficiency, etaO
- Written to <case>/postProcessing/<functionObjectName>/<time>/propellerPerformance.dat
Wake field output is controlled by the writeControl settings, including:
- Wake field text file
- Wake: 1 - UzMean/URef
- Velocity in cylindrical coordinates at xyz locations
- Written to <case>/postProcessing/<functionObjectName>/<time>/wake.dat
- Axial wake field text file
- 1 - Uz/URef at r/R and angle
- Written to <case>/postProcessing/<functionObjectName>/<time>/axialWake.dat
- Velocity surface
- Written to <case>/postProcessing/<functionObjectName>/surfaces/<time>/disk.<surfaceFormat>
Example wake field - Courtesy of Yannick Eberhard, Promarin GmbH:
Example usage
propellerInfo1
{
type propellerInfo;
libs (forces);
writeControl writeTime;
patches ("propeller.*");
URef 5; // Function1 type; 'constant' form shown here
rho rhoInf; // incompressible
rhoInf 1.2;
// Optionally write propeller performance data
writePropellerPerformance yes;
// Propeller data:
// Radius
radius 0.1;
rotationMode specified; // specified | MRF
// rotationMode = specified:
origin (0 -0.1 0);
n 25.15;
axis (0 1 0);
// Optional reference direction for angle (alpha) = 0
alphaAxis (1 0 0);
//// rotationMode = mrf
//// MRF MRFZoneName;
//// (origin, n and axis retrieved from MRF model)
// Optionally write wake text files
// Note: controlled by writeControl
writeWakeFields yes;
// Sample plane (disk) properties
// Note: controlled by writeControl
sampleDisk
{
surfaceWriter vtk;
r1 0.05;
r2 0.2;
nTheta 36;
nRadial 10;
interpolationScheme cellPoint;
errorOnPointNotFound false;
}
}
Source code
Tutorial
TOP
The particleTracks utility has been extended to include field output. The following example shows the evolution of the particle diameter for the filter tutorial case, output in VTK format:
All available fields are output by default; the new fields entry can be used to select individual fields, e.g.
cloud reactingCloud1;
sampleFrequency 1;
maxPositions 1000000;
//maxTracks 5; // optional limit on the number of tracks
setFormat <format>;
// Optional field specification; wildcards supported
// - if ommitted all fields are written
fields (d T);
The number of tracks can be limited using the maxTracks entry, where track data is now written to the postProcessing directory, e.g.:
<case>/postProcessing/lagrangian/<cloudName>/particleTracks/scalarTracks.vtk
Source code
Tutorial
TOP
glTF is a common data exchange format for virtual reality software, e.g. ESI's IC.IDO. Scenes are described using a JSON representation and the field/binary data is stored in an external file.
These changes add glTF v2 as an option when writing sampledSets and particle tracks.
Note: glTF files can also be read in ParaView
glTF format options
Controls are exposed via the formatOptions dictionary, e.g.
setFormat gltf;
formatOptions
{
...
}
Options include:
- Adding colour (RGBA):
formatOptions
{
colour yes;
}
By default, this will add colour fields named COLOR_0, COLOR_1, ... COLOR_N corresponding to each value field, using the default colour map (coolToWarm), anchoring the colour map limits to the field minimum and maximum.
Individual field specification is enabled using a fieldInfo sub-dictionary, e.g.
formatOptions
{
colour yes;
fieldInfo
{
T // Field name
{
// Optional colour map; default = coolToWarm
colourMap fire;
// Alpha channel description
alpha field; // uniform | field;
//alphaValue 0.1; // uniform alpha value
alphaField T;
normalise yes;
}
}
}
Note that when using the field option for alpha channel scaling, the selected field should be the same type as the field being output, i.e. scalar, vector etc., since the fields are grouped into their primitive types when output.
Particle tracks have some additional options:
- Static tracks can be written as a set of points along the track (lines support may be added in the future). Specification is the same as above.
- Tracks can be animated, i.e. seeding a particle at the start of the track and then updating its position as a function of time:
formatOptions
{
animate yes;
colour yes;
animationInfo
{
colour field;
colourMap rainbow;
colourField d;
// Optional colour map min and max limits
//min 0;
//max 0.002;
//alpha uniform;
//alphaValue 1;
alpha field;
alphaField d;
normalise yes;
}
}
Note that the particle colour for animated tracks remains constant; dynamic colour values are not currently supported by the format.
Source code
Tutorial
- $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter/system/sample
- $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter/constant/particleTrackProperties
- $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter/constant/particleTrackProperties.animate
Merge request
TOP
Many OpenFOAM models employ default user inputs to cater for common set-ups and simplify input dictionaries; however, these defaults can sometimes lead to unexpected behaviour or hide unknown features. The writeOptionalEntries information switch can now be used to identify default values quickly and easily. This is particularly useful when combined with the -dry-run option to limit the overall output, e.g.
Exec : rhoSimpleFoam -dry-run -info-switch writeOptionalEntries -noFunctionObjects
...
Selecting thermodynamics package
{
type heRhoThermo;
mixture pureMixture;
transport sutherland;
thermo hConst;
equationOfState perfectGas;
specie specie;
energy sensibleInternalEnergy;
}
-- Executable: rhoSimpleFoam Dictionary: "constant/thermophysicalProperties" Entry: "dpdt" Default: 1
-- Executable: rhoSimpleFoam Dictionary: "0/p.boundaryField.inlet" Entry: "useImplicit" Default: 0
-- Executable: rhoSimpleFoam Dictionary: "0/p.boundaryField.inlet" Entry: "patchType" Default:
-- Executable: rhoSimpleFoam Dictionary: "0/p.boundaryField.outlet" Entry: "useImplicit" Default: 0
-- Executable: rhoSimpleFoam Dictionary: "0/p.boundaryField.outlet" Entry: "patchType" Default:
-- Executable: rhoSimpleFoam Dictionary: "0/p.boundaryField.(?i).*walls" Entry: "useImplicit" Default: 0
-- Executable: rhoSimpleFoam Dictionary: "0/p.boundaryField.(?i).*walls" Entry: "patchType" Default:
-- Executable: rhoSimpleFoam Dictionary: "0/T.boundaryField.inlet" Entry: "useImplicit" Default: 0
-- Executable: rhoSimpleFoam Dictionary: "0/T.boundaryField.inlet" Entry: "patchType" Default:
-- Executable: rhoSimpleFoam Dictionary: "0/T.boundaryField.outlet" Entry: "phi" Default: phi
-- Executable: rhoSimpleFoam Dictionary: "0/T.boundaryField.outlet" Entry: "patchType" Default:
-- Executable: rhoSimpleFoam Dictionary: "0/T.boundaryField.(?i).*walls" Entry: "useImplicit" Default: 0
-- Executable: rhoSimpleFoam Dictionary: "0/T.boundaryField.(?i).*walls" Entry: "patchType" Default:
-- Executable: rhoSimpleFoam Dictionary: "constant/thermophysicalProperties.mixture.specie" Entry: "massFraction" Default: 1
-- Executable: rhoSimpleFoam Dictionary: "constant/thermophysicalProperties.mixture.thermodynamics" Entry: "Tref" Default: 298.15
-- Executable: rhoSimpleFoam Dictionary: "constant/thermophysicalProperties.mixture.thermodynamics" Entry: "Href" Default: 0
-- Executable: rhoSimpleFoam Dictionary: "system/fvSchemes.geometry" Entry: "type" Default: basic
TOP
The new electricPotential function object solves a steady-state equation for charge conservation to obtain the electric potential, by assuming a quasi-static electrostatic field, and employing isotropic conductivity and mixture permittivity. Optionally, it can calculate electric field, current density and free-charge density fields.
The following images show part of a verification study for a conductive-dielectric water-air mixture (López-Herrera et al., 2011), and right, a dielectric-dielectric water-air mixture:
A minimal example usage follows:
electricPotential1
{
// Mandatory entries
type electricPotential;
libs (solverFunctionObjects);
// Conditional entries
// Option-1: single-phase
sigma <scalar>;
epsilonr <scalar>;
// Option-2: multiphase
phases
{
alpha.air
{
sigma <scalar>;
epsilonr <scalar>;
}
alpha.water
{
sigma <scalar>;
epsilonr <scalar>;
}
alpha.mercury
{
sigma <scalar>;
epsilonr <scalar>;
}
...
}
// Optional entries
nCorr <label>;
writeDerivedFields <bool>;
fieldName <word>;
// Inherited entries
...
}
Source code
Tutorial
References
- López-Herrera, J. M., Popinet, S., & Herrada, M. (2011). A charge-conservative approach for simulating electrohydrodynamic two-phase flows using volume-of-fluid. Journal of computational Physics, 230(5), 1939-1955. DOI:10.1016/j.jcp.2010.11.042
TOP
The exprField function object provides a simple means of defining new fields or modifying existing ones using expression syntax, e.g.
func1
{
type exprField;
libs (fieldFunctionObjects);
field pTotal;
expression "p + 0.5*(rho*magSqr(U))";
dimensions [ Pa ];
}
It is also possible to modify an existing field. For example, to modify the previous one, restricted to particular regions of the mesh:
func1.mod
{
type exprField;
libs (fieldFunctionObjects);
field pTotal;
action modify;
// Static pressure only in these regions
fieldMask
#{
(mag(pos()) < 0.05) && (pos().y() > 0) || cellZone(inlet)
#};
expression "p";
}
The generated fields are normally stored on the object-registry, which makes them available to other parts of OpenFOAM. Of course, this can also be switched off. For example, to have a simple generator of additional post-processing fields simply avoid storing the result and only generate on write:
postpro1
{
type exprField;
libs (fieldFunctionObjects);
store false;
executionControl none;
writeControl writeTime;
...
}
Source code
Tutorial
TOP
The new comfort function object calculates values based on the ISO EN 7730:2005 for human behaviour inside rooms, typically used in HVAC analysis. Three quantities are reported:
- PPD - predicted percentage of dissatisfaction;
- PMV - predicted mean vote; and
- DR - draught rate.
PPD, PMV, and DR values are normally single values for a single room, and therefore very approximate. With CFD we have the possibility to evaluate each cell separately and hence HVAC analyses can predict more thorough, accurate and more understandable results.
These quantities are based on temperature, velocity and turbulence kinetic energy (if available).
An example usage is given below:
comfort
{
// Mandatory entries
type comfort;
libs (fieldFunctionObjects);
// Optional entries
// Clothing factor (what people wear - data are given in ISO EN 7730)
clothing 0.5;
metabolicRate 1.2;
// External work (commonly 0)
extWork 0.0;
// Radiation temperature, if not given calculated based on surface-temperatures
// Trad 0.0;
// Relative humidity
relHumidity 60.0;
// Saturation pressure, if not given will be calculated
pSat 0.0;
// Tolerance (for the loop in a sub-function to calculate the clothing temperature)
tolerance 1e-4;
// Number of iterations to calculate the clothing temperature
maxClothIter 100;
// Use the local cell velocity field?
meanVelocity false;
}
Source code
Tutorial
Attribution
- This function object was integrated from openfoam.org, who received the code contribution from Tobias Holzmann, ESI GmbH.