Based on:
Cao, L., Sun, F., Chen, T., Tang, Y., & Liao, D. (2018).
Quantitative prediction of oxide inclusion defects inside
the casting and on the walls during cast-filling processes.
International Journal of Heat and Mass Transfer, 119, 614-623.
DOI:10.1016/j.ijheatmasstransfer.2017.11.127
Co-authored-by: Kutalmis Bercin <kutalmis.bercin@esi-group.com>
- this refines commit c233961d45, which added prefix scoping.
Default is now off (v2106 behaviour).
The 'useNamePrefix' keyword can be specified on a per function basis
or at the top-level of "functions".
```
functions
{
errors warn;
useNamePrefix true;
func1
{
type ...;
useNamePrefix false;
}
func2
{
type ...;
// Uses current default for useNamePrefix
}
}
```
- at the moment there is no significant difference since FieldBase is
essentially just a refCount anyhow, but changing the inheritance
ensures that reinterpret casting from SubField -> Field will
continue to work if FieldBase is changed in the future.
A Helmholtz-like filter is applied to the original field of sensitivity
derivatives. The corresponding PDE is solved on the sensitivity patches,
using the finite area infrastructure. A smoothing radius is needed,
which is computed based on the average 'length' of the boundary faces,
if not provided by the user explicitly.
If an faMesh is provided, it will be used; otherwise it will be created
on the fly based on either an faMeshDefinition dictionary in system or
one constructed internally based on the sensitivity patches.
Surface gradient scheme with under-/over-relaxed
full or limited explicit non-orthogonal correction.
A minimal example by using system/fvSchemes:
snGradSchemes
{
snGrad(<term>) relaxed;
}
and by using system/fvSolution:
relaxationFactors
{
fields
{
snGrad(<term>) <relaxation factor>;
}
}
A second-order gradient scheme using face-interpolation,
Gauss' theorem and iterative skew correction.
Minimal example by using system/fvSchemes:
gradSchemes
{
grad(<term>) iterativeGauss <interpolation scheme> <number of iters>;
}
- fix overly aggressive match in the API value
- allow `INTELMPI*` generic value, this can be used to specify something
like INTELMPI_custom and populate the corresponding wmake rule
manually
STYLE: mention FOAM_BUILDROOT in wmake -help-full output
STYLE: adjust openfoam shell session welcome information
- adjust internal variable names to reduce collision potential
- improve handling of openfoam -etc=...
Description
Writes point data in glTF v2 format
Two files are generated:
- filename.bin : a binary file containing all scene entities
- filename.gltf : a JSON file that ties fields to the binary data
The output can contain both geometry and fields, with additional support
for colours using a user-supplied colour map, and animation of particle
tracks.
Controls are provided via the optional formatOptions dictionary.
For non-particle track data:
\verbatim
formatOptions
{
// Apply colours flag (yes | no ) [optional]
colours yes;
// List of options per field
fieldInfo
{
p
{
// Colour map [optional]
colourMap <colourMap>;
// Colour map minimum and maximum limits [optional]
// Uses field min and max if not specified
min 0;
max 1;
// Alpha channel [optional] (uniform | field)
alpha uniform;
alphaValue 0.5;
//alpha field;
//alphaField T;
//normalise yes;
}
}
}
\verbatim
For particle tracks:
\verbatim
formatOptions
{
// Apply colours flag (yes | no) [optional]
colours yes;
// Animate tracks (yes | no) [optional]
animate yes;
// Animation properties [optional]
animationInfo
{
// Colour map [optional]
colourMap <colourMap>;
// Colour [optional] (uniform | field)
colour uniform;
colourValue (1 0 0); // RGB in range [0-1]
//colour field;
//colourField d;
// Colour map minimum and maximum limits [optional]
// Note: for colour = field option
// Uses field min and max if not specified
min 0;
max 1;
// Alpha channel [optional] (uniform | field)
alpha uniform;
alphaValue 0.5;
//alpha field;
//alphaField T;
//normalise yes;
}
}
\endverbatim
Note
When writing particle animations, the particle field and colour properties
correspond to initial particle state (first data point) and cannot be
animated (limitation of the file format).
For more information on the specification see
https://www.khronos.org/registry/glTF/
The utility will now add field data to all tracks (previous version only
created the geometry)
The new 'fields' entry can be used to output specific fields.
Example
cloud reactingCloud1;
sampleFrequency 1;
maxPositions 1000000;
fields (d U); // includes wildcard support
STYLE: minor typo fix
