openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2022-06-08T10:41:01Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/544ENH: EBRSM: new elliptic-blending Reynolds-stress turbulence model2022-06-08T10:41:01ZKutalmış BerçinENH: EBRSM: new elliptic-blending Reynolds-stress turbulence model#### Acknowledgement
OpenCFD would like to acknowledge and thank **Prof. Rémi Manceau**, **Dr. Michael Karl Stoellinger**, and **Dr. Ardalan Javadi** for their contributions, elaborate suggestions and help, and critical recommendations....#### Acknowledgement
OpenCFD would like to acknowledge and thank **Prof. Rémi Manceau**, **Dr. Michael Karl Stoellinger**, and **Dr. Ardalan Javadi** for their contributions, elaborate suggestions and help, and critical recommendations. Highly appreciated.
#### Aim
Implement and evaluate the elliptic-blending Reynolds-stress turbulence models proposed by [Manceau (2015) - Appendix C](https://doi.org/10.1016/j.ijheatfluidflow.2014.09.002).
#### Methodology
- Plane channel flow at ReTau=180, 395, 590 (Moser et al., 1991) and =4179 (Lozano-Duran & Jimenez, 2014)
- NASA Turbulence Modelling Resource on various physics:
- 2DCC: 2D Convex curvature boundary layer
- 2DML: 2D Mixing layer
- 2DB: 2D Bump-in-channel
- 2DZP: 2D Zero pressure gradient flat plate
- 2DANW: 2D Airfoil near-wake
#### Results
**Plane channel flow, ReTau=180**
<img src="/uploads/6c9899cad5929f65d869d3d63a90c55f/all_setups_yPlus_vs_uPlus.png" width="25%" height="25%">
<img src="/uploads/6520c01105e1aaa63434d67badf9b83e/all_setups_yPlus_vs_Ruu.png" width="25%" height="25%">
<img src="/uploads/1f99612fea236e501b1c117c43b3a694/all_setups_yPlus_vs_Rvv.png" width="25%" height="25%">
<img src="/uploads/439522e1fa9c3735e0cd244b1369e297/all_setups_yPlus_vs_Rww.png" width="25%" height="25%">
<img src="/uploads/52a8f9c9f28106cea6abe6ce7c33bad4/all_setups_yPlus_vs_Ruv.png" width="25%" height="25%">
<img src="/uploads/9b2f1e92fabff3104609ae03bbdd51fd/all_setups_yPlus_vs_epsilonPlus.png" width="25%" height="25%">
<img src="/uploads/c1d4cddd0b62a53bd317c655d3da9e48/all_setups_yPlus_vs_kPlus0.png" width="25%" height="25%">
<img src="/uploads/5056b4ce464c70c2c9d4b7c3037f1382/yPlus_vs_f.png" width="25%" height="25%">
**Plane channel flow, ReTau=4179**
<img src="/uploads/ad6eec1e96e581e4f617487a3fb092c3/all_setups_yPlus_vs_uPlus.png" width="25%" height="25%">
<img src="/uploads/3f5b20a7fe449a1964e8a937ddaafe50/all_setups_yPlus_vs_Ruu.png" width="25%" height="25%">
<img src="/uploads/2ffc52fe7918911d3cfcc8873bdf737b/all_setups_yPlus_vs_Rvv.png" width="25%" height="25%">
<img src="/uploads/8f9a7156be4fdf8e185535fff44ff845/all_setups_yPlus_vs_Rww.png" width="25%" height="25%">
<img src="/uploads/1cd605e4beb3c201fdce620b94e45559/all_setups_yPlus_vs_Ruv.png" width="25%" height="25%">
<img src="/uploads/8016b8dcc9a4ac15878e4351afb5107c/yPlus_vs_f.png" width="25%" height="25%">
**2DCC: 2D Convex curvature boundary layer**
<img src="/uploads/98cf3ae928d18f353728139aff7e90ac/all_setups_u_vs_y.png" width="25%" height="25%">
<img src="/uploads/362d12cc1f2386a13b493310bd4fe5b5/all_setups_Ruu_vs_y.png" width="25%" height="25%">
<img src="/uploads/1ed623a0b9a551169db65812d170f927/all_setups_Rvv_vs_y.png" width="25%" height="25%">
<img src="/uploads/c62dbb4686d4e4f4f190f8be87c4d7cf/all_setups_Ruv_vs_y.png" width="25%" height="25%">
<img src="/uploads/c1af0cb694fc137cd04273b464721fe4/x_vs_Cf_bottom.png" width="25%" height="25%">
<img src="/uploads/f2f1b39122d2c97dbf7d146cd30274b5/x_vs_Cp_bottom.png" width="25%" height="25%">
**2DML: 2D Mixing Layer**
<img src="/uploads/725943103926d796e672bbe984661fc6/all_setups_u_vs_y.png" width="25%" height="25%">
<img src="/uploads/25fb821f6490576c16e60d9e2c7c76ed/all_setups_Ruu_vs_y.png" width="25%" height="25%">
<img src="/uploads/8733ada0f7d73afbc7c0765dcbec5b52/all_setups_Rvv_vs_y.png" width="25%" height="25%">
<img src="/uploads/1cb31d6fda8b755f3d85accdaee2f876/all_setups_Rww_vs_y.png" width="25%" height="25%">
<img src="/uploads/a4cc5479508bb025d19c8c5d7539ab65/all_setups_Ruv_vs_y.png" width="25%" height="25%">
### Meta-data
EP#1805
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error
### Discussion
- In general, `EBRSM` yields better predictions for `R` and turbulence quantities in comparison to `kOmegaSST` model.
- But _not always_: For example, for `2DML: 2D Mixing Layer`, the `R` predictions of `EBRSM` is worse than those of `kOmegaSST`. The reason seems to be that the `EBRSM` could not reach the target convergence levels for this specific case.
- Predictions for `U` are similar.
- In general, less stable than `kOmegaSST`.
- For example, `2DZP: 2D Zero pressure gradient flat plate` and `2DANW: 2D Airfoil near-wake` cases are unstable.
- Initial values/initialisations seem to be important to
`EBRSM` in terms of numerical stability
and fidelity.
- The two-step automatic initialisation method proposed by (Manceau (n.d.)) should be preferred
over precursor simulations.
- Low-quality mesh cases are challenging,
especially meshes with high-aspect ratios
are prone to instabilities.
- Max relaxation factor for `R=0.4`. Avoid `R~O(0.05)` at all costs.
- Realizability conditions are not
automatically satisfied.
- Multiphase and compressible cases are
not explored by the academia.
### Future work
- Test scope should be extended further for:
- Multiphase-flow cases
- Compressible flow cases
- Dynamic-mesh cases
- Overset meshes
- Mesh (un)refinements
- Collated-data format
- Hybrid and single precisions
- New methods should be developed to stabilise `EBRSM` for low-quality meshes.v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/542General enhancement to icoReactingMultiphaseInterFoam solver, sub-models and ...2022-06-22T09:18:53ZSergio FerrarisGeneral enhancement to icoReactingMultiphaseInterFoam solver, sub-models and FO's1) Name changing and namespace used for some multi phase class used in icoReactingMultiphaseInterFoam.
2) Creating a new derivedFvPatch for thermal BC's (detached from TurbulenceCompressible) which allows to
use phase system models i...1) Name changing and namespace used for some multi phase class used in icoReactingMultiphaseInterFoam.
2) Creating a new derivedFvPatch for thermal BC's (detached from TurbulenceCompressible) which allows to
use phase system models in FO's. This new lib was added to all the thermal solvers
3) Adding new diffusion-based mass transfer model to icoReactingMultiphaseInterFoam
4) Improving consistency of Hf between phases (updated tutorials entries)
5) HeatFlux and htc FO's are available to use with icoReactingMultiphaseInterFoam
NOTE: There is memory leak problem at the end of the run when using icoReactingMultiphaseInterFoam and 'fieldFunctionObjects' is loaded usng lddOpen. NEED TO BE REVIEWEDv2206Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/539ENH: norm: add new field function object2022-05-27T11:58:44ZKutalmış BerçinENH: norm: add new field function objectEP1871
<img src="/uploads/3a948c9898bfea03397a550370578d30/image.png" width="50%" height="50%">
<img src="/uploads/656a0375d29062e3bed28a0b6d6bb78b/image.png" width="50%" height="50%">
<img src="/uploads/99411e71d94ea8e2f98e28e8412ca7...EP1871
<img src="/uploads/3a948c9898bfea03397a550370578d30/image.png" width="50%" height="50%">
<img src="/uploads/656a0375d29062e3bed28a0b6d6bb78b/image.png" width="50%" height="50%">
<img src="/uploads/99411e71d94ea8e2f98e28e8412ca720/image.png" width="50%" height="50%">
<img src="/uploads/27a831d096d9368dffdfd06da7bf301e/image.png" width="50%" height="50%">
<img src="/uploads/49e80a7e4480b71fafdf6b115e7ef837/image.png" width="50%" height="50%">
<img src="/uploads/a215b20f7b5af40c947277050e183c5c/image.png" width="50%" height="50%">
##### Tests
- [x] `linux64ClangDPInt32Opt`
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] Alltestv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/536ENH: sixDoFRigidBodyMotion: add new softWall restraint2022-05-19T10:58:41ZKutalmış BerçinENH: sixDoFRigidBodyMotion: add new softWall restraintEP1745
##### Tests
- [x] `linux64ClangDPInt32Opt`
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] AlltestEP1745
##### Tests
- [x] `linux64ClangDPInt32Opt`
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] Alltestv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/532ENH: turbulentDigitalFilter: Synthetic fluctuations of scalars2022-06-07T20:12:35ZKutalmış BerçinENH: turbulentDigitalFilter: Synthetic fluctuations of scalars**Aim**
To enable synthetic fluctuations of scalars (e.g. temperature or contaminant concentrations) for the `turbulentDigitalFilterInlet` boundary condition.
**Previous status**
- Produces only vector-based fluctuations
- Input en...**Aim**
To enable synthetic fluctuations of scalars (e.g. temperature or contaminant concentrations) for the `turbulentDigitalFilterInlet` boundary condition.
**Previous status**
- Produces only vector-based fluctuations
- Input entries of mean and Reynolds stresses are limited to be either constant or simple wall-normal profiles
- Contains unresolved bugs:
- #1725
- #2262
- #2267 (Parallelisation)
- #2329 (FSM is inoperative)
- Domain rotations/translations are not possible
- Parallelisation and scaling are problematic
- Restart is problematic
- Mapping fluctuations onto an inlet patch is problematic and limited to only the nearest-cell option
- Adjustable time-step simulations are not possible
**Improvements**
- Produces vector- or scalar-based fluctuations
- New input-entry types:
- Mean and Reynolds stresses have become `PatchFunction1` type
- Time-variant input for mean and Reynolds stresses is possible
- Number of input entries have been simplified by reducing the number from 16 to 8, most of which are default valued.
- Resolves the reported bugs
- Domain rotations/translations are improved
- Users can set a local coordinate system
- Parallelisation and scaling are improved
- Restart is improved
- Mapping fluctuations onto an inlet patch is improved and generalised
- Users can select an AMI mapping method for the mapping operation
- Adjustable time-step simulations are possible for the FSM option
- Removes Taylor's frozen turbulence assumption for the streamwise integral scale calculations
**Resolved bugs**
#1725 #2262 #2267 #2329
**Methodology**
<img src="/uploads/ed664afc764a1894db265b8210796b0d/image.png" width="50%" height="50%">
<img src="/uploads/4fc57b37db8180bb261c3d808bd14ff8/image.png" width="50%" height="50%">
#### Results
**DFM - only vector**
<img src="/uploads/b8b00f5758bc3998f81fb80908c121b6/image.png" width="85%" height="85%">
**DFM - only scalar**
<img src="/uploads/10ab195728e01971af04b14e01a109fc/image.png" width="85%" height="85%">
**DFM - vector+scalar**
<img src="/uploads/b1a26f36c48a1d63c1c09d17b2d6f7a3/image.png" width="85%" height="85%">
**FSM - only vector**
<img src="/uploads/58877dd2e728e8e91fe8f188356c09ef/image.png" width="85%" height="85%">
**FSM - only scalar**
<img src="/uploads/422232e58ae5ddcf60ce7d47877e3262/image.png" width="85%" height="85%">
**FSM - vector+scalar**
<img src="/uploads/f159b9a384b792912bf2d5c89b76c4f0/image.png" width="85%" height="85%">
### Meta-data
EP#1730
* [x] Clean compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error
### Future work - Constraints
- Test scope should be extended further for:
- Integral length scales
- Domain rotations and/or translations
- Multiphase-flow cases
- Dynamic-mesh cases
- Overset meshes
- Mesh (un)refinements
- Collated-data format
- Hybrid and single precisions
- `transformPoints` utility has no effect on `boundaryData` input, which can slow down case preparations for input sets which need to be rotated/translated
- Scalar-based condition
- No constraints on nonpositive output
- Scarce and ambiguous academic resources
- No cross-correlations
- Not easy to produce/find benchmark data from theory or measurements
- Usefulness is not clarified by academia
- DFM
- Incomplete parallelisation of the three-dimensional separable convolution due to the lack of no open-source algorithms
- ~~The use of `redistributePar -decompose` utility is not supported.~~v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/529dynamic mesh (un)refinement: compatible with mesh motion2022-03-07T16:07:20ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdynamic mesh (un)refinement: compatible with mesh motion### Summary
See #2395### Summary
See #2395Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/524refactor coordSet writers (#2347)2022-04-12T14:54:13ZMark OLESENrefactor coordSet writers (#2347)### Summary
Replace old, stateless, templated _writer_ class with a _coordSetWriter_ class that more closely resembles _surfaceWriter_. It is time-aware and can be used as a streamer with sample/write of each field instead of accumulati...### Summary
Replace old, stateless, templated _writer_ class with a _coordSetWriter_ class that more closely resembles _surfaceWriter_. It is time-aware and can be used as a streamer with sample/write of each field instead of accumulating all of the sampled fields ahead of time.v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/523ENH: runTimeControl - enable resetting the trigger to an earlier instant2022-02-28T07:07:47ZAndrew HeatherENH: runTimeControl - enable resetting the trigger to an earlier instantThe runTimeControl function object can activate further function objects using
triggers. Previously the trigger index could only advance; this change set
allows users to set smaller values to enable function object recycling, e.g.
Repea...The runTimeControl function object can activate further function objects using
triggers. Previously the trigger index could only advance; this change set
allows users to set smaller values to enable function object recycling, e.g.
Repeat for N cycles:
1. average the pressure at a point in space
2. when the average stabilises, run for a further 100 iterations
3. set a new patch inlet velocity
- back to (1)
Added a 'none' condition that acts as a pass-through/no-op with the option to
set a new trigger value.
Refactored the averageCondition run-time condition and valueAverage FO to use
a common basev2206Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/521Lagrangian modelling updates/new features2021-12-15T10:46:58ZAndrew HeatherLagrangian modelling updates/new featuresMultiple enhancements:
- `PatchInjectionModel`: updated to include additional velocity specification options
- `ConeNozzleInjection`: updated to enable dynamic position and direction vectors
- `FaceInteraction`: new `cloudFunctionObject...Multiple enhancements:
- `PatchInjectionModel`: updated to include additional velocity specification options
- `ConeNozzleInjection`: updated to enable dynamic position and direction vectors
- `FaceInteraction`: new `cloudFunctionObject`
## PatchInjectionModel
The parcel initial velocity can now be set using the new `velocityType`
entry, taking one of the following options:
- `fixedValue` : (default) same as earlier versions, requires `U0`
- `patchValue` : velocity set to seed patch face value
- `zeroGradient` : velocity set to seed patch face adjacent cell value
Example usage:
```
model1
{
type patchInjection;
massTotal 1;
SOI 0;
parcelBasisType mass;
patch cylinder;
duration 10;
parcelsPerSecond 100;
velocityType patchValue;
//velocityType zeroGradient;
//U0 (-10 0 0);
flowRateProfile constant 1;
sizeDistribution
{
type normal;
normalDistribution
{
expectation 1e-3;
variance 1e-4;
minValue 1e-5;
maxValue 2e-3;
}
}
}
```
See the new $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/spinningDisk tutorial
## ConeNozzleInjection
- Now only has the options `point` and `disk` (deprecated `movingPoint`)
- moving state is based on the type of `Function1`
- The position and direction entries are `Function1`-types, e.g. for the `table` type the entries could be:
```
position table
(
( 0 (0.1 0.5 0.5))
(0.2 (0.5 0.9 0.5))
(0.4 (0.9 0.5 0.5))
(0.6 (0.5 0.1 0.5))
(0.8 (0.5 0.5 0.9))
(1.0 (0.5 0.9 0.5))
(1.2 (0.5 0.5 0.1))
(1.4 (0.5 0.1 0.5))
);
direction table
(
( 0 ( 1 0 0))
(0.2 ( 0 -1 0))
(0.4 (-1 0 0))
(0.6 ( 0 1 0))
(0.8 ( 0 0 -1))
(1.0 ( 0 -1 0))
(1.2 ( 0 0 1))
(1.4 ( 0 1 0))
);
```
## FaceInteraction
Enables particles to interact with mesh faces (described using `faceZones`).
```
faceInteraction1
{
type faceInteraction;
faceZones
(
(blockageFaces stick)
// (blockageFaces escape)
// (blockageFaces rebound) // not applicable for this test case (!)
);
dMin 0;
dMax 1;
}
The `faceZones` entry is a list of (`faceZoneName` `interactionType`), where interaction type is either `stick`, `escape` or `rebound`.
No tutorial added yet; for testing: reactingParcelFoam case: [filter.tgz](/uploads/e0034538f6c9bb85c0cfa3e1068a6ba2/filter.tgz)v2112https://develop.openfoam.com/Development/openfoam/-/merge_requests/519Added new propellerInfo function object2021-12-14T16:45:32ZAndrew HeatherAdded new propellerInfo function object## Calculates propeller performance and wake field properties.
Controlled by executeControl:
- Propeller performance
- Thrust coefficient, Kt
- Torque coefficient, 10*Kq
- Advance coefficient, J
- Open water efficiency, etaO
-...## Calculates propeller performance and wake field properties.
Controlled by executeControl:
- Propeller performance
- Thrust coefficient, Kt
- Torque coefficient, 10*Kq
- Advance coefficient, J
- Open water efficiency, etaO
- Written to postProcessing/<name>/<time>/propellerPerformance.dat
Controlled by writeControl:
- Wake field text file
- Wake: 1 - UzMean/URef
- Velocity in cylindrical coordinates at xyz locations
- Written to postProcessing/<name>/<time>/wake.dat
- Axial wake field text file
- 1 - Uz/URef at r/R and angle
- Written to postProcessing/<name>/<time>/axialWake.dat
- Velocity surface
- Written to postProcessing/<name>/surfaces/time>/disk.<fileType>
Example wake field - Courtesy of Yannick Eberhard, Promarin GmbH
![v2112-postProcessing-propellerInfo](/uploads/77553caacb0835eb100773b7b10bfbb7/v2112-postProcessing-propellerInfo.png)
## Usage
Example of function object specification:
```
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;
}
}
```
Where the entries comprise:
| Property | Description | Required | Deflt value |
| ------ | ------ |--|-- |
| type | Type name: propellerInfo | yes | |
| log | Write to standard output | no | no |
| patches | Patches included in the forces calculation | yes |
| p | Pressure field name | no | p |
| U | Velocity field name | no | U |
| rho | Density field name | no | rho |
| URef | Reference velocity | yes | |
| rotationMode | Rotation mode (see below) | yes | |
| origin | Sample disk centre | no* | |
| n | Revolutions per second | no* | |
| axis | Propeller axis | no* | |
| alphaAxis | Axis that defines alpha=0 dir | no | |
| MRF | Name of MRF zone | no* | |
| originOffset | Origin offset for MRF mode | no | (0 0 0) |
| writePropellerPerformance| Write propeller performance text file | yes | |
| writeWakeFields | Write wake field text files | yes | |
| surfaceWriter | Sample disk surface writer | no* | |
| r1 | Sample disk inner radius | no | 0 |
| r2 | Sample disk outer radius | no* | |
| nTheta | Divisions in theta direction | no* | |
| nRadial | Divisions in radial direction | no* | |
| interpolationScheme | Sampling interpolation scheme | no* | cell |
Note
- `URef` is a scalar `Function1` type, i.e. supports `constant`, `table`, lookup values
- `rotationMode` is used to set the origin, axis and revolutions per second
- if set to `specified` all 3 entries are required
- note: `origin` is the sample disk origin
- if set to `MRF` only the MRF entry is required
- to move the sample disk away from the MRF origin, use the `originOffset`
- if `writePropellerPerformance` is set to on|true:
- `propellerPerformance` text file will be written
- if `writeWakeFields` is set to on|true:
- wake and `axialWake` text files will be written
- if the `surfaceWriter` entry is set, the sample disk surface will be written
- extents set according to the `r1` and `r2` entries
- discretised according to the `nTheta` and `nRadial` entries
Note: sign-off in EP 1719v2112https://develop.openfoam.com/Development/openfoam/-/merge_requests/512INT: age/comfort: New field function objects2021-12-13T17:07:01ZKutalmış BerçinINT: age/comfort: New field function objects(Explanatory content by @THO - I just added/removed few things)
### Summary
#### Function object: age
This functionObject calculates the so called `age of air` inside any domain. This is useful in HVAC analysis to check the ventilation...(Explanatory content by @THO - I just added/removed few things)
### Summary
#### Function object: age
This functionObject calculates the so called `age of air` inside any domain. This is useful in HVAC analysis to check the ventilation of a room, office, theater, cinema, academic rooms etc.
The function object is similar to use the `scalarTransport` function object + adding a source term via `fvOptions`. However, the main advantage of the `age` functionObject is that the user does not have to provide the `volScalarField`. It is generated automatically based on the patches a user uses:
- All patches of type patch (mainly used for inlet/outlets in HVAC) does get an `inletOutlet` boundary type while the `inletValue` is set to 0 (fresh air)
- All other patches of any other type, e.g., walls, are set to `zeroGradient`
- The `volScalarField` is generated during the execute routine - could be improved by checking if it is in the registry already, if yes take it otherwise create it
- For each time-step the steady-state solution of the age is calculated, and therefore the user can control the convergence:
- by setting the `tolerance` for the initial residual
- `nCorrs` for how many corrector loops are executed
- If either the `nCorrs` or the `tolerance` is reached, the loop is left and the field is stored
#### Function object: comfort
This functionObject calculated values based on the `ISO EN 7730:2005` for human behavior inside rooms. This is mainly used in HVAC analysis. The functionObject calculated (until now) three quantities:
PPD - predicted percentag of dissatisfaction
PMV - predicted mean vote
DR - draught rate
The calculations of PPD, PMV, and DR are normally single values for a single room: so its just rough guess. With CFD we have the possibility to evaluate each numerical cell separately and hence, HVAC analysis can predict more accurate and more understandable results. HVAC analysis also used for swimming bath, sauna areas and much more.
These quantities are based on the following computed fields:
Temperature
Velocity
Turbulent kinetic energy (if available)
Optional input parameters:
Clothing factor (what people wear - data are given in ISO EN 7730)
Methabolic rate
externalWork (commonly 0)
radiation temperature, if not given calculated based on surface-temperatures
relative humidity
saturation pressure, if not given will be calculated in the function object otherwise
tolerance (for the loop in a sub-function to calculate the clothing temperature)
maxClothIter (number of iterations to calculate the clothing temperature)
meanVelocity; either use the local cell velocity field for each
### Resolved bugs
N/A
### Details of new models
#### Function object: age
* Based on laboratory experiments:
```
Bartak, M., Cermak, M., Clarke, J.A., Denev, J.,
Drkal, F., Lain, M., Macdonald, I.A., Majer, M., Stankov, P., 2001.
Experimental and numerical study of local mean age of air.
In: Proceedings of the 7th International Building Performance
Simulation Association (IBPSA) Conference, Rio de Janeiro, Brazil.
Bartak, M., Beausoleil-Morrison, I., Clarke, J.A., Denev, J., Drkal, F.,
Lain, M., Macdonald, I.A., Melikov, A., Popiolek, Z., Stankov, P., 2002.
Integrating CFD and building simulation. Building and Environment 37, 865–871.
```
* A laboratory experiment of a test room with mixing ventilation, where the measurements were taken by a tracer-gas concentration-decay method.
* "At first a uniform tracer-gas distribution in the test room was reached, then the tracer-gas marking was cut off and the decay of the tracer-gas concentration due to the fresh (non-marked) ventilating air was measured."
![image](/uploads/cf5f1628cedd6258f2f37c20ff8b6ca2/image.png)
![image](/uploads/0e09e4056eca0fbf58582e17ebc4725b/image.png)
#### Function object: comfort
Unluckily, there is no validation case available for this function object. The only possible "check" is to use a one-cell domain, set parameters (as given in the EN ISO 7730:2005) and check if the same results are outputted.
### Risks
- No changes in user input
- No changes in existing outputv2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/510ENH: interfaceOxideRate: new mass transfer model for icoReactingMultiphaseInt...2021-12-09T17:05:24ZSergio FerrarisENH: interfaceOxideRate: new mass transfer model for icoReactingMultiphaseInterFoam solver- Adding new mass transfer model 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-f...- Adding new mass transfer model 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
The model calculates the oxide produced at the air-liquid interface of a VOF system.
- A new BC was created to quantify the amount of oxide mass absorbed by walls.v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/503sampledSets - enable writer construction from dictionary; glTF export2021-12-06T13:14:10ZAndrew HeathersampledSets - enable writer construction from dictionary; glTF export## sampledSets - added writer construction from dictionary
The `sampledSets` `writer` is now constructed with a dictionary to enable custom options using a new `formatOptions` dictionary - see example below.
## glTF format
glTF is a c...## sampledSets - added writer construction from dictionary
The `sampledSets` `writer` is now constructed with a dictionary to enable custom options using a new `formatOptions` dictionary - see example below.
## glTF format
glTF is a common data exchange format for virtual reality software, e.g. [ESI's IC.IDO](https://www.esi-group.com/products/virtual-reality). Scenes are described using a JSON representation and the field/binary data is stored in an external file.
These changes add [glTF v2](https://www.khronos.org/registry/glTF/) as an option when writing `sampledSets` and particle tracks.
Note: glTF files can also be read in ParaView v5.9
### Additions:
- The `particleTracks` utility:
- output path has been updated to `postProcessing/lagrangian/<cloudNme>/particleTracks/`;
- has a new option to limit the number of tracks exported; and
- supports field export (previously only geometry was written).
- example:
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);
- glTF format support added to sampledSets, e.g.
type sets;
libs (sampling);
interpolationScheme cellPointFace;
setFormat gltf;
### 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.
![Screenshot_from_2021-11-26_14-40-53](/uploads/28f5fd037e102b9887a38c08d59cf5eb/Screenshot_from_2021-11-26_14-40-53.png)
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
![Screenshot_from_2021-11-26_14-40-27](/uploads/a3f687dd4ccd9d5cca5e80e830c0fdef/Screenshot_from_2021-11-26_14-40-27.png)
- 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.
## Examples
See:
- $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter/system/sample
- $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter/constant/particleTrackProperties
- $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter/constant/particleTrackProperties.animatev2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/502ENH: New schemes for non-orthogonal meshes2021-12-08T12:08:02ZKutalmış BerçinENH: New schemes for non-orthogonal meshes### Summary
**Aim:**
Improvement of numerical **stability** of **non-orthogonal** mesh simulations **only** via changes in the **diffusion operator** handling.
**(Theory) What is face non-orthogonality:**
- "The angle between the ce...### Summary
**Aim:**
Improvement of numerical **stability** of **non-orthogonal** mesh simulations **only** via changes in the **diffusion operator** handling.
**(Theory) What is face non-orthogonality:**
- "The angle between the centroid vector and the unit normal vector is the orthogonality angle." (Wimhurst, 2019)
**(Theory) Why is face non-orthogonality important:**
- Can affect the discrete diffusion operator:
- Numerical stability (hence cost)
- Level of errors
- Numerical stability
- Larger explicit treatment -> less stability
- Level of errors
- Larger corrections -> larger truncation errors
- Cannot be reduced by mesh refinement
**(Theory) What is the technical challenge in face non-orthogonality:**
- "The difficulty is to evaluate the dot product of the normal vector and the velocity gradient on the cell face." (Wimhurst, 2019)
**(Theory) Treatments in OpenFOAM:**
- Explicit correction by using an over-relaxed-type unit-normal vector decomposition
### Resolved bugs
N/A
### Methodology
**Problem definition:**
- Convergence rate
- Explicit component can become limiting factor for numerical stability
- During initial iterations, especially for steady-state runs or when starting from uniform fields in transient runs
- Yet its removal reduces accuracy
- Convergence order
- Non-orthogonality treatments are neglected at boundaries (except cyclic conditions)
- Even minor non-orthogonality on patches reduce the convergence order for cases where Dirichlet/Neumann boundary conditions are applied. (Noriega et al., 2018)
**A solution: Field relaxation**
- Field relaxation for explicit non-orthogonality components
- Under-relaxation for numerical stability
- Over-relaxation for numerical cost
- Implementation: a Laplacian scheme
- Based on an idea from `nextFoam`
- Named `relaxedNonOrthoLaplacian`
- Implementation: a surface-normal gradient scheme:
- Named `relaxedSnGrad`
**Test case:**
- The DNS study of a smooth-wall plane channel flow by (Moser et al., 1999) where the friction Reynolds number of the flow is ReTau=395.
**Metrics:**
- Numerical stability
- Simulation crashes or not
- Prediction fidelity
- Flow field predictions vs DNS statistics
**Control variable:**
<img src="/uploads/5d6921a672ee7d70d6672d48505861d5/image.png" width="50%" height="50%">
### Results
![image](/uploads/5b997d95e965d8a895b387a6d37f762d/image.png)
![image](/uploads/496cedf11adafb1a9933d0d10deca83d/image.png)
![image](/uploads/cb03fc29aece34350d7576a1c21126e6/image.png)
![image](/uploads/f3cbd51e47723f982277520b42517794/image.png)
![image](/uploads/57b268055f93e271c3766fd78be95290/image.png)
![image](/uploads/e50faee3fb0988e7f557fd5302cbf299/image.png)
### Discussion
**What happened?**
- New schemes
- Did not dampen initial residuals unlike nextFoam observations (at least for this particular case)
- Improved prediction fidelity for above 50 degrees
- Prevented simulations crashing after a certain non-orthogonality angle (above 50)
- Numerical cost
- For below-50-degree non-orthogonality cases, the runtime remained similar to that of the base
- For above-50-degree cases, the numerical cost seems to be reduced
<img src="/uploads/59a1e422f5be56ac6e631e60c7b82e22/image.png" width="50%" height="50%">
**What do the results mean in practise? (How will it change in how we do things?)**
- New schemes **may** be used
- to avoid any simulation crashes due to non-orthogonality treatments
- without affecting the fidelity of numerical predictions
- without affecting numerical cost estimations
- more tests are needed
### Risks
- No changes in existing output.
- No changes in existing user input.
### Constraints
- No finite-area numerics
- Needs extensive tests to assume safe for single-phase, multiphase and overset finite-volume applications
- No boundary treatments for Dirichlet and Neumann conditions
### Tests
* [x] Compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No change in output with respect to the develop HEAD + no error
##### References
- Wimhurst, A. (2019). Mesh Non-Orthogonality. https://tinyurl.com/49b55tzw
- Wimhurst, A. (2019). Mesh Non-Orthogonality 2: The Over-Relaxed Approach https://tinyurl.com/234h7hbt
- Noriega et al. (2018). A case-study in open-source CFD code verification, Part I: Convergence rate loss diagnosis. DOI: 10.1016/j.matcom.2017.12.002v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/500ENH: New gradient scheme iterativeGaussGrad2021-12-08T11:05:44ZKutalmış BerçinENH: New gradient scheme iterativeGaussGrad### Summary
**Aim:**
Improvement of numerical **fidelity** only via improving **gradient** computations for meshes with **non-zero face skewness**.
**(Theory) What is face skewness:**
- Level of closeness of the following two spatial...### Summary
**Aim:**
Improvement of numerical **fidelity** only via improving **gradient** computations for meshes with **non-zero face skewness**.
**(Theory) What is face skewness:**
- Level of closeness of the following two spatial points:
- Face intersection of the PN vector between cell centres of an owner cell and a neighbour cell
- Face centre of the common face of the two cells
**(Theory) Why is face skewness important:**
- Prediction fidelity
- Any deviation from face centre as the face average centre reduces the second-order accuracy (i.e. non-zero face skewness)
- Hence OpenFOAM has various skewness corrections for centre-to-face interpolations
- Numerical stability
- Reduces the diagonal dominance of the discrete Poisson operator which slows down convergence. ADI (i.e. alternating-direction implicit) type preconditioners also become less effective.
**(Theory) What is the technical challenge in face skewness:**
- Omission wherever possible due to cost concerns rather than a true technical challenge
- Gradient computations are accounted for ~20% of a typical simulation
**(Theory) Treatments in OpenFOAM:**
- Many methods to quantify skewness
- OpenFOAM has its own definition
- Skewness formulations in `checkMesh` and `snappyHexMesh` are a bit different
- Various skewness corrections available
- `skewCorrectedSnGrad` surface-normal gradient scheme
- `skewCorrected` surface interpolation scheme
- No corrections on boundary skewness
- No corrections in Gauss-Green gradient computations
- Not needed for `leastSquares` and `pointLinear` based gradient schemes
### Resolved bugs
N/A
### Methodology
**Problem definition:**
- Face skewness is not accounted during any Gauss-Green gradient computations.
- Incorporation of face skewness into gradient computations **may or may not** improve the level of prediction fidelity.
**A problem solution: Iterative Gauss gradient**
- Add an outer loop around the gradient and skew-correction vector computations
- Add an optional relaxation factor inside the gradient computation
<img src="/uploads/d8930fd27b2515bb0cfd25814927918e/image.png" width="50%" height="50%">
**Test case:**
- Very difficult to design a test case where skewness is isolated from non-orthogonality
- [Manufactured solution](https://www.openfoam.com/documentation/guides/latest/doc/guide-schemes-gradient-example.html): A two-dimensional triangle-cell domain where theoretical gradient is square-root of 2 in each co-ordinate direction
**Metrics:**
- Numerical stability
- Simulation crashes or not
- Prediction fidelity - Level of discrepancy between theoretical and numerical values:
<img src="/uploads/8eb4d34c480bf6683a8814a24938c7b2/image.png" width="50%" height="50%">
- Arithmetic average of error field
- Coefficient of variation (CoV) of error field
- Relative standard deviation: std/mean
- Measure of amount of dispersion
- Low CoV: Values are close to mean
- High CoV: Values spread out over a wider range, potentially indicating outliers with respect to the mean
**Control variable:**
- Skewness is not the control variable since changing skewness also changes non-orthogonality in general
- Therefore:
- We fixed skewness and non-orthogonality with a fixed-geometry test case
- Control variable becomes the gradient scheme itself
- We quantified the performance of each gradient scheme with the chosen metric and compared them with each other
**Mesh metrics:**
![image](/uploads/69778f9a3803614e35436dd8aac054a8/image.png)
### Results
![image](/uploads/26960502a9e3d24f21e98798ab070e4b/image.png)
![image](/uploads/fe29294c40d765384b930115275d9259/image.png)
![image](/uploads/ecb33932f656ded148e1ebd2afa2218f/image.png)
![image](/uploads/5f80d7f935a35a84b5da51a4484601fe/image.png)
![image](/uploads/11ca5223abb62764749ed71a5b01dce7/image.png)
![image](/uploads/836727a0db9861dac012a9caa9355f12/image.png)
![image](/uploads/127620e5dbc5bc140a2d888e2c1419f1/image.png)
### Discussion
**What happened?**
- New iterative Gauss scheme
- Reduced errors in internal fields in comparison to other Gauss schemes
- Reduced errors in boundary fields in comparison to least square schemes
- Increasing number of iterations monotonically reduced errors
- Application of interpolation-scheme limiters increased errors
**What do the results mean in practise? (How will it change in how we do things?)**
- The new scheme **may** be used to improve prediction fidelity for gradient computations on meshes with skewness and non-orthogonality
- More tests are needed for:
- Effects of extreme levels of face skewness
- Cost estimations
- The results **do not suggest** that the new scheme can improve numerical stability
### Risks
- No changes in existing output.
- No changes in existing user input.
### Constraints
- No finite-area
- Needs extensive tests to assume safe for single-phase, multiphase and overset finite-volume applications
- No boundary treatments for Dirichlet and Neumann conditions
### Tests
* [x] Compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No change in output with respect to the develop HEAD + no errorv2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/493ENH: new RANS model for geophysical applications2021-11-08T18:58:08ZKutalmış BerçinENH: new RANS model for geophysical applications### Summary
- ENH: kL: new RANS model for geophysical applications
- STYLE: atmosphericModels: regroup atmospheric turbulence models
- ENH: kEpsilonLopesdaCosta: enable this RANS model for compressible applications
- TUT: atmFlatTer...### Summary
- ENH: kL: new RANS model for geophysical applications
- STYLE: atmosphericModels: regroup atmospheric turbulence models
- ENH: kEpsilonLopesdaCosta: enable this RANS model for compressible applications
- TUT: atmFlatTerrain: add an example for kL RANS model
- BUG: atmFlatTerrain: fix input settings in the plot script
### Resolved bugs (If applicable)
- A small issue in `atmFlatTerrain/precursor/plot` has been corrected.
### Details of new models (If applicable)
- For a given case, the `kL` model reduces numerical costs approximately by one-third in comparison to the `kEpsilon` model for geophysical applications.
- A set of results obtained from the `atmFlatTerrain` and `atmForestStability` tutorials (left: kEpsilon, right: kL):
![image](/uploads/79d0f1db91983844da41db3af79599b6/image.png)
![image](/uploads/e1190ba19b50ddc5a093660d7f2ee4cd/image.png)
![image](/uploads/d6999f8f9d833e90acaf0a941a428c1d/image.png)
![image](/uploads/c8fbc676998046df8f8498e935ba1f21/image.png)
![image](/uploads/03df4d3859b04af634bb2c05d7391080/image.png)
![image](/uploads/d6c34c1c9e2144096b73363e8f12297c/image.png)
### Risks
- No changes in user input.
- No changes are expected in output.
- The directory structure of `src/atmosphericModels` has been changed. Therefore, the location of the directory `kEpsilonLopesdaCosta` has also been changed. Might affect few minor things for a few developers. Not crucial, IMHO.
### Tests
* [x] Compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No change in output with respect to the develop HEAD + no errorv2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/471ENH: Adding new permeable boundary conditions and a tutorial2021-06-17T21:01:28ZSergio FerrarisENH: Adding new permeable boundary conditions and a tutorial- 4d2e6e63f9b99d97dc83d2ee7b41d0fc47030d88: ENH: Adding new permeable boundary conditions
- `prghPermeableAlphaTotalPressure` for `p_rgh`
- `pressurePermeableAlphaInletOutletVelocity` for `U`
- new helper class for pressure-r...- 4d2e6e63f9b99d97dc83d2ee7b41d0fc47030d88: ENH: Adding new permeable boundary conditions
- `prghPermeableAlphaTotalPressure` for `p_rgh`
- `pressurePermeableAlphaInletOutletVelocity` for `U`
- new helper class for pressure-related BCs: `updateableSnGrad`
- 2a3b41e523cba5490a7cbd408e92a5c964e970a2: TUT: new multiphase tutorial: `damBreakPermeable`v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/470ENH: Added new multiRegion function object2021-06-16T11:48:22ZAndrew HeatherENH: Added new multiRegion function objectWrapper that clones the supplied object for each region.
Simplifies setting up identical post-processing requirements for multi-
region cases. Applies the supplied function to all regions by default.
Example of function object specific...Wrapper that clones the supplied object for each region.
Simplifies setting up identical post-processing requirements for multi-
region cases. Applies the supplied function to all regions by default.
Example of function object specification:
multiRegion
{
type multiRegion;
libs (utilityFunctionObjects);
...
function
{
// Actual object specification
type fieldMinMax;
libs (fieldFunctionObjects);
fields (<field1> .. <fieldN>);
}
// Optional entries
regions (region1 region2);
}
Where the entries comprise:
Property | Description | Required | Default value
type | Type name: multiRegion | yes |
function | Function object sub-dictionary | yes |
regions | List of region names | no | allv2106Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/468AMI improvements2021-06-18T10:32:20ZAndrew HeatherAMI improvements- Added new faceAreaWeightAMI2D AMIMethod:
- performs intersection using a new 2D triangle class;
- candidate face matches set using an AABBTree method (vs advancing front for
faceAreaWeightAMI).
- Use by setting the AMIMethod...- Added new faceAreaWeightAMI2D AMIMethod:
- performs intersection using a new 2D triangle class;
- candidate face matches set using an AABBTree method (vs advancing front for
faceAreaWeightAMI).
- Use by setting the AMIMethod entry when specifying the AMI in the
constant/polyMesh/boundary file, e.g.
AMI
{
type cyclicACMI;
AMIMethod faceAreaWeightAMI2D; // new method
Cbb 0.1; // optional coefficient
nFaces 1000;
startFace 100000;
matchTolerance 0.0001;
transform noOrdering;
neighbourPatch AMI1;
nonOverlapPatch AMI1_non_overlap;
}
- The optional Cbb coeffcient controls the size of the bounding box used when
looking for candidate pairs; the value of 0.1 is the default and worked well
for a large range of test cases. For badly matched AMI patches this may need
to be increased.
- Deprecated the partialFaceAreaWeightAMI class - primarily used by ACMI:
- functionality now offered by the AMI variants.
- ~~NOTE: both AABBTree and octree variants included for review; ***ONLY 1 METHOD TO BE ADDED***~~
EDIT: octree method remoedv2106Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/457support parallel creation of finiteArea meshes with on-the-fly decomposition ...2021-05-28T18:14:55ZMark OLESENsupport parallel creation of finiteArea meshes with on-the-fly decomposition of fields #2084v2106Sergio FerrarisSergio Ferraris