openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2023-06-23T07:39:56Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/588Draft: New renumbering based on Hamiltonian path2023-06-23T07:39:56ZAlon ZameretDraft: New renumbering based on Hamiltonian path### Summary
Included a new renumbering method called 'hpathRenumber' which reorder the mesh cells using an Hamiltonian path approach.
### Details of new models
Hamiltonian path is a path that traverses through the mesh faces and visi...### Summary
Included a new renumbering method called 'hpathRenumber' which reorder the mesh cells using an Hamiltonian path approach.
### Details of new models
Hamiltonian path is a path that traverses through the mesh faces and visits each cell exactly once. The Hamiltonian path approach tries to find such a path and renumber the mesh accordingly. This method ensures that after the mesh renumbering, consecutive cells in memory will likely share a common geometrical face. This in turn may allow for more efficient memory access and better vectorization performances when traversing the mesh.
![2D_Cylinder_Hpath](/uploads/90b36b3ca4136da32aaa93090c9300c0/2D_Cylinder_Hpath.png)
### Usage
Described below is the renumberMethodDict example used to apply Hamiltonian path renumbering:
```
method hpath;
hpathCoeffs
{
layered true;
}
```
The 'layered' argument (default true) controls whether the algorithm will separate the mesh cells into different 'layers' (otherwise, all cells are considered to be within the same layer). The layer separation approach is known to obtain better results and improved run-time for 3D cases, while 2D cases where a simpler Hamiltonian path may exist will benefit from avoiding the layer separation.
The algorithm will than try to find an Hamiltonian path traversing through all the cells sharing the same layer, and report the Hamiltonian path accuracy obtained.
The path accuracy is defined as the percentage of consecutive cells in the renumbered order that share a common face.v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/587Draft: New decomposition method (multiNodeDecomp)2023-06-23T07:40:04ZAlon ZameretDraft: New decomposition method (multiNodeDecomp)### Summary
A new decomposition method 'multiNodeDecomp' which extends the capabilities of the multi-level decomposition method found within OpenFOAM while maintaining full backwards compatibility.
The multiNodeDecomp allow users contro...### Summary
A new decomposition method 'multiNodeDecomp' which extends the capabilities of the multi-level decomposition method found within OpenFOAM while maintaining full backwards compatibility.
The multiNodeDecomp allow users control over the properties of each node within the decomposition tree, as opposed to multi-level decomposition which supports level-based modifications.
### Details of new decomposition method
The multiNodeDecomp method adds the following capabilities:
1. Support decomposition to un-even nodes by changing the number of children of each node. For example:
```
multiNodeCoeffs {
method metis;
domains (3 4);
domains[0] (8);
}
```
In the example above, the mesh will be decomposed into 3 domains, where the first domain (domain[0]) will be further decomposed into 8 subdomains, while the remaining 2 domains will be decomposed into 4 subdomains only.
This will result in a total of 20 subdomains.
Note that the user passes a list value, which allows to have a different number of levels under different branches of the decomposition tree.
2. Simplified interface for decomposition weights - uniform/relative weight distribution may be used to initialize the weight of each node. The user may later overwrite any of the nodes weight.
```
weightsInitialization relative;
weight[0][3] 2;
```
'Uniform' initialization will recursively set all of the nodes weights to 1, while the 'Relative' initialization sets each nodes weight to the number of leaves in its decomposition subtree.
The weight of a node is then used during its parent's decomposition to control the sub-mesh size it will receive.
3. Modify the nodes decomposition method:
```
method[2] {
method scotch;
coeffs {
...
}
}
```
This will overwrite the method of the third subdomain of the root to use scotch and the given coefficients.
### Syntax
multiNodeDecomp supports setting the decomposition properties above on a level scope (parameter[] value) or on a node scope (parameter[#nodeIndex] value).
The square brackets indicate indices of the children we want to modify (0 based indexing). The user may specify ranges by using a hyphen ([0-3]) or specifying all of the children by using empty brackets ([]).v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/586ENH: pureZoneMixture: different mixture properties according to cellZone2022-12-14T15:39:18ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: pureZoneMixture: different mixture properties according to cellZone### Summary
Use a different mixture on a per-cell basis.
### Details of new models (If applicable)
In the `thermoPhysicalProperties` one can now select the new `pureZoneMixture` model. It is a drop-in replacement for `pureMixture` wh...### Summary
Use a different mixture on a per-cell basis.
### Details of new models (If applicable)
In the `thermoPhysicalProperties` one can now select the new `pureZoneMixture` model. It is a drop-in replacement for `pureMixture` where the mixture properties itself are sub selected by cellZones. In below example (for a solid mesh) there are two cellZones, `heater1` and `heater2`. The second, `heater2` has slightly different properties:
```
thermoType
{
type heSolidThermo;
mixture pureZoneMixture; //pureMixture;
transport constIso;
thermo hConst;
equationOfState rhoConst;
specie specie;
energy sensibleEnthalpy;
}
mixture
{
heater1
{
specie
{
molWeight 50;
}
transport
{
kappa 80;
}
thermodynamics
{
Hf 0;
Cp 450;
}
equationOfState
{
rho 8000;
}
}
heater2
{
//- Start off from heater1 properties
${heater1}
//- Selectively overwrite properties
equationOfState
{
rho 4000;
}
}
}
```
### Risks
- the input works with the usual explicit boundary conditions (`compressible::turbulentTemperatureRadCoupledMixed`) for `chtMultiRegionFoam`. The only difference is that the per-cell properties are looked up through the cellZone the cell is in.
- the two cellZones can also not be separated (i.e. share faces) in which case attention has to be paid to the interpolation scheme (e.g. `harmonic`)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/585Misc. changes in finite-area methods2023-02-08T14:44:32ZKutalmış BerçinMisc. changes in finite-area methods#### Acknowledgement
OpenCFD would like to acknowledge and thank **Matthias Rauter** for his help and discussions. Highly appreciated.#### Acknowledgement
OpenCFD would like to acknowledge and thank **Matthias Rauter** for his help and discussions. Highly appreciated.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/584ENH: dynamicContactAngleForce: new finite-area contact-angle force model2022-12-09T13:09:22ZKutalmış BerçinENH: dynamicContactAngleForce: new finite-area contact-angle force modelDocumentation: [MR584-contact-line-movement.pdf](/uploads/4630ced2e0840306c54a220827cab6b4/MR584-contact-line-movement.pdf)
Test case: [MR584-contact-line-movement.zip](/uploads/d8e429759478273657c4dadbe94f76fe/MR584-contact-line-moveme...Documentation: [MR584-contact-line-movement.pdf](/uploads/4630ced2e0840306c54a220827cab6b4/MR584-contact-line-movement.pdf)
Test case: [MR584-contact-line-movement.zip](/uploads/d8e429759478273657c4dadbe94f76fe/MR584-contact-line-movement.zip)
##### Metadata
EP#1996
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/583ENH: added option to control log frequency of lagrangian calculations2022-12-09T10:05:42ZAndrew HeatherENH: added option to control log frequency of lagrangian calculations### Summary
Cross ref: EP#1945
Lagrangian cloud calculations can generate significant amounts of reporting, e.g.
Solving2-D cloud reactingCloud1
Cloud: reactingCloud1
Current number of parcels = 994
Curre...### Summary
Cross ref: EP#1945
Lagrangian cloud calculations can generate significant amounts of reporting, e.g.
Solving2-D cloud reactingCloud1
Cloud: reactingCloud1
Current number of parcels = 994
Current mass in system = 0.009735873844
Linear momentum = (0.0001652067978 0.0001039875528 0)
|Linear momentum| = 0.0001952093676
Linear kinetic energy = 0.0001660812145
Average particle per parcel = 19.21387643
Injector model1:
- parcels added = 994
- mass introduced = 0.01
Parcel fate: system (number, mass)
- escape = 0, 0
Parcel fate: patch (walls|cyc.*) (number, mass)
- escape = 0, 0
- stick = 0, 0
Parcel fate: patch (inlet|outlet) (number, mass)
- escape = 0, 0
- stick = 0, 0
Temperature min/max = 275.039299, 275.4193813
Mass transfer phase change = 0.000264126156
Mass transfer devolatilisation = 0
Mass transfer surface reaction = 0
If multiple injectors and/or more interaction patches are present, the quantity of output information can increase dramatically.
For some workflows it can be beneficial to reduce the amount of output by reporting this data every `n` time steps instead of every step.
### Details of new models (If applicable)
Added an optional `logFrequency` keyword to the cloud solution input dictionary, e.g. in the `<case>/constant/*CloudProperties`
solution
{
active true;
coupled false;
transient yes;
cellValueSourceCorrection off;
maxCo 0.3;
logFrequency 3; // <--- NEW ENTRY
...
}
The value is set to 1 by default to maintain backwards compatibility.
### Risks
- Multiple small changes across the code - should be low risk.
- use of `Log_` vs `Log` annoying but needed for use in templated code - suggestions welcomev2212Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/582Cleaner separation global/local/self communication, cleaner responsibility fo...2022-12-05T19:08:24ZMark OLESENCleaner separation global/local/self communication, cleaner responsibility for fileHandler ownershipv2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/581ENH: KinematicSurfaceFilm: add option to specify interacting parcel types2022-12-01T12:52:07ZKutalmış BerçinENH: KinematicSurfaceFilm: add option to specify interacting parcel typesEP2019
Test case: [kinematicParcelFoam-splashPanelFilm.zip](/uploads/430a45abf4d47c4bd01b11b43197822f/kinematicParcelFoam-splashPanelFilm.zip)
This changeset adds a new entry 'parcelTypes' which can specify the list of
parcel type IDs ...EP2019
Test case: [kinematicParcelFoam-splashPanelFilm.zip](/uploads/430a45abf4d47c4bd01b11b43197822f/kinematicParcelFoam-splashPanelFilm.zip)
This changeset adds a new entry 'parcelTypes' which can specify the list of
parcel type IDs interacting with a surface film. If the entry
is omitted, all particle types are considered.
```
surfaceFilmModel kinematicSurfaceFilm;
kinematicSurfaceFilmCoeffs
{
interactionType absorb;
// Optional list of participating parcel IDs
parcelTypes (10);
}
```
To set the parcel type by injector, 'injectorID' entry can be used
when specifying the injector models, e.g.
```
injectionModels
{
model1
{
type <injectionModelType>;
// Optional injector ID
// - if ommitted, parcels use '-1'
injectorID 10;
...
}
}
```
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/580ENH: Brun dripping film injection2022-12-01T13:58:35ZKutalmış BerçinENH: Brun dripping film injectionEP2009
Test case: [dripping-test.zip](/uploads/972e684819c0a3b9b833e0d68e1d7560/dripping-test.zip)
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorEP2009
Test case: [dripping-test.zip](/uploads/972e684819c0a3b9b833e0d68e1d7560/dripping-test.zip)
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/579ENH: solidIsothermalReactionRate: new solid reaction rate model2022-11-29T14:31:17ZKutalmış BerçinENH: solidIsothermalReactionRate: new solid reaction rate modelEP2005, EP1629
##### Usage example
In `combustion/fireFoam/LES/simplePMMApanel/constant/panelRegion/reactions`:
```
reactions
{
_tmp_
{
#include "<constant>/panelRegion/thermo.solid"
}
charReaction
{
...EP2005, EP1629
##### Usage example
In `combustion/fireFoam/LES/simplePMMApanel/constant/panelRegion/reactions`:
```
reactions
{
_tmp_
{
#include "<constant>/panelRegion/thermo.solid"
}
charReaction
{
type irreversibleIsothermalSolidReaction;
reaction "PMMA = gas";
C <scalar>;
Tpc <scalar>;
Elat <scalar>;
Cp ${../_tmp_/PMMA/thermodynamics/Cp};
}
#remove _tmp_
}
```
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/578ENH: new objective functions for adjoint-based optimisation2022-12-23T15:26:02ZVaggelis PapoutsisENH: new objective functions for adjoint-based optimisation### Summary
Added five new objective functions for use in adjoint-based optimisation.
### Details of new models
The new objective functions mainly target internal flow optimisation problems. A short description and an indicative exam...### Summary
Added five new objective functions for use in adjoint-based optimisation.
### Details of new models
The new objective functions mainly target internal flow optimisation problems. A short description and an indicative example for each of them follows. All figures that follow depict the velocity magnitude.
**flowRate**
Computes and minimizes/maximizes the volume-flow rate through a given set of patches. An indicative application follows, in which the flow-rate though the upper part of the duct should be maximized (flow from left to right).
| _Initial geometry (52.8% of the flow-rate goes through the upper part)_ | _Optimised geometry (53.7% of the flow-rate goes through the upper part)_ |
| ------ | ------ |
| ![flowRate.0000](/uploads/765e7369a8ced43451e8ab29656a4c7e/flowRate.0000.png) | ![flowRate.0004](/uploads/e9aa8c5f8aec559742e622ca04e4bbc6/flowRate.0004.png) |
Tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/fork-uneven/flowRate
Source code: $FOAM_SRC/optimisation/adjointOptimisation/adjoint/objectives/incompressible/objectiveFlowRate
**flowRatePartition**
Used to distribute the inlet flow-rate to outlet patches with prescribed target percentages. An indicative application follows, in which the equal distribution of the inlet flow-rate to the two outlets is targeted.
| _Initial geometry (52.8%/47.2% distribution between the upper/lower outlets)_ | _Optimised geometry (equally distributed flow)_ |
| ------ | ------ |
| ![flowRate.0000](/uploads/765e7369a8ced43451e8ab29656a4c7e/flowRate.0000.png) | ![flowRatePartition.0009](/uploads/d631dc909a26f2bf22ff96ac06f59145/flowRatePartition.0009.png) |
Tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/fork-uneven/flowRatePartition
Source code: $FOAM_SRC/optimisation/adjointOptimisation/adjoint/objectives/incompressible/objectiveFlowRatePartition
**uniformityPatch**
Enhances the flow uniformity by minimizing the velocity variance computed on prescribed (outlet) patches (the lower outlet patch in this case).
| _Initial geometry_ | _Optimised geometry (velocity variance reduced by 34%)_ |
| ------ | ------ |
| ![flowRate.0000](/uploads/765e7369a8ced43451e8ab29656a4c7e/flowRate.0000.png) | ![uniformityPatchGeom.0004](/uploads/05507242bca1a0ea8b40d0aaa6f8dc7d/uniformityPatchGeom.0004.png)|
Tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/fork-uneven/uniformityPatch
Source code: $FOAM_SRC/optimisation/adjointOptimisation/adjoint/objectives/incompressible/objectiveUniformityPatch
**uniformityCellZone**
Enhances the flow uniformity by minimizing the velocity variance within prescribed cellZones.
In this case, the boundaries of the target cellZone are highlighted in black.
| _Initial geometry_ | _Optimised geometry (velocity variance reduced by 34%)_ |
| ------ | ------ |
| ![uniformityCellZone.0001](/uploads/a8bc0863c192f7e57ced2cc26a658885/uniformityCellZone.0001.png) |![uniformityCellZone.0010](/uploads/d3e6f8ee6bb6114e1dbaa381a6eef70f/uniformityCellZone.0010.png) |
Tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/sbend/laminar/opt/unconstrained/uniformityCellZone
Source code: $FOAM_SRC/optimisation/adjointOptimisation/adjoint/objectives/incompressible/objectiveUniformityCellZone
**powerDissipation**
Computes and minimizes the fluid power dissipation that takes place within given cellZones. If the cellZone covers the entire flow domain, this objective is equivalent to volume flow-rate weighted total pressure losses (i.e. the `PtLosses` objective function).
The boundaries of the target cellZone are highlighted in black.
| _Initial geometry_ | _Optimised geometry (Power dissipation reduced by 57% within the cellZone)_ |
| ------ | ------ |
| ![powerDissipation-partial.0001](/uploads/7e1d9b473bd08e06a7131a953bc9c1fc/powerDissipation-partial.0001.png) | ![powerDissipation-partial.0009](/uploads/ede4871e1ae40c46bf0509e15fe0b47e/powerDissipation-partial.0009.png) |
Tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/sbend/turbulent/SA/opt/powerDissipation
Source code: $FOAM_SRC/optimisation/adjointOptimisation/adjoint/objectives/incompressible/objectivePowerDissipation
Manual: [adjointOptimisationFoamManual_v2212.pdf](/uploads/7abcfe652f40106694b877e261233d70/adjointOptimisationFoamManual_v2212.pdf)v2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/577ENH: fvOptions: add writeFile functionality2022-12-08T11:37:58ZKutalmış BerçinENH: fvOptions: add writeFile functionalityEP2028
EP1947
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorEP2028
EP1947
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/576ENH: Added new parallelFvGeometryScheme2022-12-08T11:14:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: Added new parallelFvGeometryScheme# OpenFOAM parallel-consistent geometry calculation
This release adds a new `parallel` geometry calculation method. It is used as a wrapper around other geometry calculation methods:
```
geometry
{
type parallel;
// Op...# OpenFOAM parallel-consistent geometry calculation
This release adds a new `parallel` geometry calculation method. It is used as a wrapper around other geometry calculation methods:
```
geometry
{
type parallel;
// Optional underlying geometry calculation. Default is 'basic'.
geometry
{
type highAspectRatio;
}
}
```
It
- applies owner side face geometry (centre, normal (negated)) to the other side
- recalculates cell-based geometry of affected cells
It is mainly interesting in single-precision in that it removes the
different truncation error from circulating in different direction. This
can cause problems when calculating global transformations e.g.
```
--> FOAM FATAL ERROR: (openfoam-2206)
bad size -653174757
From void Foam::List<T>::doResize(Foam::label) [with T = Foam::vectorTensorTransform; Foam::label = int]
in file lnInclude/List.C at line 84.
#0 Foam::error::printStack(Foam::Ostream&)
#1 Foam::error::simpleExit(int, bool) at ??:?
#2 Foam::error::exiting(int, bool)
#3 Foam::List<Foam::vectorTensorTransform>::doResize(int)
#4 Foam::globalIndexAndTransform::determineTransformPermutations() at ??:?
```
Note that it does not change the point positions so any other calculated geometry (e.g. cell-closedness) might be affected.
Tutorial:
Source code:
- src/finiteVolume/fvMesh/fvGeometryScheme/parallelAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/575ENH: leastSquaresEdgeInterpolation: new edge interpolation method2022-12-01T12:24:45ZKutalmış BerçinENH: leastSquaresEdgeInterpolation: new edge interpolation methodDocumentation: [MR575-edgeInterpolation-scheme-23-Nov-22.pdf](/uploads/70de4f1a6735f8bf16fb630a5c158e18/MR-edgeInterpolation-scheme-23-Nov-22.pdf)
Test case: [MR575-edgeInterpolation-scheme-23-Nov-22.zip](/uploads/324646ab02997f421292bc...Documentation: [MR575-edgeInterpolation-scheme-23-Nov-22.pdf](/uploads/70de4f1a6735f8bf16fb630a5c158e18/MR-edgeInterpolation-scheme-23-Nov-22.pdf)
Test case: [MR575-edgeInterpolation-scheme-23-Nov-22.zip](/uploads/324646ab02997f421292bceda13cd9e8/finiteArea.zip)
##### Metadata
EP#1996
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/574ENH: inv: fall back to pseudo-inverse for singular tensors2022-12-01T12:09:07ZKutalmış BerçinENH: inv: fall back to pseudo-inverse for singular tensorsDocumentation: [MR574-pseudo-inverse-23-Nov-22.pdf](/uploads/bff6ab3706726d703da2d48ec449ff5e/Pseudo-inverse-23-Nov-22.pdf)
Test case: [MR574-pseudo-inverse-23-Nov-22-cube.zip](/uploads/a4f55cc2891d31510e39cb0cd27f1510/MR574-pseudo-inve...Documentation: [MR574-pseudo-inverse-23-Nov-22.pdf](/uploads/bff6ab3706726d703da2d48ec449ff5e/Pseudo-inverse-23-Nov-22.pdf)
Test case: [MR574-pseudo-inverse-23-Nov-22-cube.zip](/uploads/a4f55cc2891d31510e39cb0cd27f1510/MR574-pseudo-inverse-cube.zip)
##### Metadata
EP#1996
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/573Feature updated core2023-02-14T14:49:50ZMark OLESENFeature updated core- provide container methods such as `front()`, `back()`, `push_back()` etc that are commonly used in the STL containers. This should help with swapping code between OpenFOAM and other projects and (in the future) make the code easier to ...- provide container methods such as `front()`, `back()`, `push_back()` etc that are commonly used in the STL containers. This should help with swapping code between OpenFOAM and other projects and (in the future) make the code easier to read for newcomers.
- reduce the use of SLList in a few more places to avoid repeated memory allocations within loops
- provide point/vector `dist()` and `distSqr()` methods for differences. This avoids intermediate variables and looping (should be more cache friendly).
- new mesh access method `cellBb` to return the boundBox of a mesh cell. Uses cached cellPoints (if available) or calculates from the face points. Eliminates similar code fragments that were scattered about the code
- improved functionality and efficiency for boundBox and treeBoundBox
- more consistent naming and handling of indexedOctree and treeData components.
Changes were originally rolled into MR !568, but grew too large for that.v2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/572BUG: avoid excessive recalculation of map for moving meshes2022-11-21T13:21:58ZAndrew HeatherBUG: avoid excessive recalculation of map for moving meshesCross ref EP#2016Cross ref EP#2016v2212Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/571ENH: Evapotranspiration utilities2022-12-08T11:36:30ZKutalmış BerçinENH: Evapotranspiration utilitiesEP1950EP1950v2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/570Updates for ensight writing2022-11-15T17:02:06ZMark OLESENUpdates for ensight writingKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/569ENH: resolutionIndex: new function object to evaluate LES/DES resolution2022-11-24T10:16:58ZKutalmış BerçinENH: resolutionIndex: new function object to evaluate LES/DES resolution#### Acknowledgement
OpenCFD would like to acknowledge and thank **[Prof. Ismail Celik](https://directory.statler.wvu.edu/faculty-staff-directory/ismail-celik)** for his contributions, elaborate suggestions and help, and critical recomm...#### Acknowledgement
OpenCFD would like to acknowledge and thank **[Prof. Ismail Celik](https://directory.statler.wvu.edu/faculty-staff-directory/ismail-celik)** for his contributions, elaborate suggestions and help, and critical recommendations. Highly appreciated.
#### Problem statement
Grid independency studies and grid
adaptation for implicit LES/DES are nontrivial
and intractable due to the inherent coupling
between spatial resolution and subgrid-scale
modelling.
#### Problem solution
- In the literature, various metrics which do not
use any experimental or DNS data and which
is based on a single mesh were introduced.
- To enable assessments for LES/DES
resolution, a single-mesh resolution index
with three submodels is introduced:
- Pope (2000)'s index using turbulent kinetic
energy variables,
- Celik et al. (2005) and Celik et al. (2009)'s
index using
- Effective Kolmogorov length scale, and
- Effective viscosity.
#### Theory
<img src="/uploads/ad75d2ce147e118b0d200a05b7ad4744/Screenshot_from_2022-11-15_15-16-45.png" width="50%" height="50%">
<img src="/uploads/9669fbd2183fd483fc759fec5abfa443/Screenshot_from_2022-11-15_15-17-35.png" width="50%" height="50%">
<img src="/uploads/d98e042f34c73f8908cbf4a477174f46/Screenshot_from_2022-11-15_15-17-42.png" width="50%" height="50%">
#### Usage
<img src="/uploads/78433a8ae1a87f96c21ecfb341fb22ea/Screenshot_from_2022-11-15_15-17-50.png" width="50%" height="50%">
<img src="/uploads/0ca3187362cd7ab19aa28cfa9537d47c/Screenshot_from_2022-11-15_15-17-58.png" width="50%" height="50%">
<img src="/uploads/bc3db2cd28f3421b59d0cccc09328870/Screenshot_from_2022-11-15_15-18-06.png" width="50%" height="50%">
<img src="/uploads/9531120c8da53982b8be355003dfb596/Screenshot_from_2022-11-15_15-18-14.png" width="50%" height="50%">
#### Tests
[resolutionIndex-tests.zip](/uploads/889447b92fa794ac6482894b63e40b6d/resolutionIndex-tests.zip)
#### Results
![Screenshot_from_2022-11-15_15-22-13](/uploads/397de8e179ac7d423aec04436fea533f/Screenshot_from_2022-11-15_15-22-13.png)
![Screenshot_from_2022-11-15_15-22-22](/uploads/2cbd8f4146a4af6a822612af3aa23353/Screenshot_from_2022-11-15_15-22-22.png)
![Screenshot_from_2022-11-15_15-22-29](/uploads/ba00ded6583dd4bb9cdb6340a50f7d75/Screenshot_from_2022-11-15_15-22-29.png)
![Screenshot_from_2022-11-15_15-22-39](/uploads/b2b5bfd848dcd71a221540aa32e5cc65/Screenshot_from_2022-11-15_15-22-39.png)
#### Discussion
- Resolution-index models need good
estimators for the subgrid-scale turbulent
kinetic energy (ksgs) field.
- The DES models of `SpalartAllmaras` seem to
produce zero-valued ksgs fields – Bug ticket
is issued: [GL2620](https://develop.openfoam.com/Development/openfoam/-/issues/2620)
- DES models may need a chain of
operations – see 'system/{controlDict,FOresolutionIndex}' in
DES cases in order to mask out the RANS regions.
#### References
- Pope, S. B. (2000). Turbulent flows. Cambridge, UK: Cambridge Univ. Press
- Celik, I. B., Cehreli Z. N., Yavuz I. (2005). Index of resolution quality for large
eddy simulations. Journal of Fluids Engineering. 127:949–958.
- Celik, I., Klein, M., & Janicka, J. (2009). Assessment measures for engineering LES applications.
Journal of fluids engineering, 131(3)
#### Metadata
EP#1997
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2212Andrew HeatherAndrew Heather