openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2020-06-24T21:12:39Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/367AMI code enhancements2020-06-24T21:12:39ZAndrew HeatherAMI code enhancements### Summary
**Note: this is beta-level code and will receive further updates in future releases**
This change set includes:
- New option for `cyclicAMI` and `cyclicACMI` patches to perform topological updates to enforce a 1-to-1 m...### Summary
**Note: this is beta-level code and will receive further updates in future releases**
This change set includes:
- New option for `cyclicAMI` and `cyclicACMI` patches to perform topological updates to enforce a 1-to-1 match between source and target patches to ensure conservation across AMI patches and greatly reduced pressure field perturbations. Changes based on ref [1]
- Deprecated `directAMI`; replaced by `nearestFaceAMI`
- Significant code refactoring
### Resolved bugs (If applicable)
- General AMI conservation issues/noisy pressure predictions
### Details of new models (If applicable)
- Backwards compatibility [should be] maintained
- New topological changes triggered by using a special mesh motion solver: `dynamicFvMesh dynamicMotionSolverFvMeshAMI;`
- this may be absorbed into the 'standard' `dynamicMotionSolverFvMesh` model in future releases
- Test case: [mixerVesselAMI2D_with-boundary-layers.tgz](/uploads/4ca838c78e139007cb6f2f06026bdf07/mixerVesselAMI2D_with-boundary-layers.tgz)
| dynamicMotionSolverFvMesh | dynamicMotionSolverFvMeshAMI |
| ------ | ------ |
| ![plot](/uploads/37f8e095ad01c8c10dcdb9ab40ffa74c/plot.png) v2006| ![plot](/uploads/ad90049926e774bd3127256f86f0e075/plot.png) v2006|
| ![plot](/uploads/7a0930907ab64ac5941c6bcf781e17ba/plot.png) v1912| |
Note: since the AMI code triggers topological updates, to reconstruct parallel cases:
- use `reconstructParMesh` to reconstruct the mesh at each time, followed by `reconstructPar` to reconstruct the fields; or
- use `redistributePar -reconstruct` to reconstruct both mesh and fields (in parallel)
- Code refactoring has enabled greater control of the AMI; the AMIMethod can now be set in the `polyMesh/boundary` file, e.g.
```
AMI2
{
type cyclicAMI;
inGroups 1(cyclicAMI);
nFaces 96;
startFace 6336;
matchTolerance 0.0001;
transform noOrdering;
neighbourPatch AMI1;
// New optional entries
AMIMethod faceAreaWeightAMI;
restartUncoveredSourceFace 1;
}
```
### Deprecations
The `directAMI` method has been deprecated and replaced by the faster and more robust, new `nearestFaceAMI` method. The new method creates a 1-to-1 mapping based on the nearest face.
### Risks
- Significant change to AMI code
- Not only affects cyclic patches, but other areas of the code that make use of the tooling, e.g.:
- mapped patches
- mapFieldsPar
- region models (film modelling)
- mapping function objects
### Known issues/to check
When using `dynamicMotionSolverFvMeshAMI`
- restart behaviour not currently available
### Tests
Checked on the following cases:
- pimpleFoam/laminar/mixerVesselAMI2D
- pimpleFoam/RAS/oscillatingInletACMI2D
- XiDyMFoam/annularCombustorTurbine
- {customer turbo machinery}
For each, the `dynamicMotionSolverFvMesh` option recovers v1912 behaviour
### References
[1] H.J. Aguerre, S. Márquez Damián J.M. Gimenez, N.M.Nigro, *Conservative handling of arbitrary non-conformal interfaces using an efficient supermesh*, Journal of Computational Physics 335(15)21-49. 2017. https://doi.org/10.1016/j.jcp.2017.01.018
### Acknowledgements
- Many thanks to Horacio Aguerre @aguerrehoracio and Santiago Márquez @santiagomarquezd for bringing the methodology to our attention and for many useful discussions and testing throughout these developments.v2006https://develop.openfoam.com/Development/openfoam/-/merge_requests/329BUG: add switch for nu:DphitEff in kEpsilonPhitF (fixes #1560)2020-01-21T12:28:10ZKutalmış BerçinBUG: add switch for nu:DphitEff in kEpsilonPhitF (fixes #1560)Including `nu` in `DphitEff` even though it is not present in (LUU:Eq. 17)
provided higher level of resemblance to benchmarks for the tests considered,
particularly for the peak skin friction (yet, pressure-related predictions
...Including `nu` in `DphitEff` even though it is not present in (LUU:Eq. 17)
provided higher level of resemblance to benchmarks for the tests considered,
particularly for the peak skin friction (yet, pressure-related predictions
were unaffected). Users can switch off `nu` in `DphitEff` by using
`includeNu` entry in `kEpsilonPhitFCoeffs` in order tofollow the
reference paper thereat. `includeNu` is left `true` by default.
See GitLab issue #1560,
- removes redundant `phit()` and `f()` access funcs,
- replaces `dimensionedScalar` with `dimScalar` to gain space.
LUU: Laurence, D. R., Uribe, J. C., & Utyuzhnikov, S. V. (2005).v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/372BUG: provide setup backward-compat for actuationDiskSourceCoeffs2020-06-18T20:59:51ZKutalmış BerçinBUG: provide setup backward-compat for actuationDiskSourceCoeffs#1732 @Prashant#1732 @Prashantv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/349CONT: Addition of compressibleIsoInterFoam and PLIC2020-06-22T11:17:41ZSergio FerrarisCONT: Addition of compressibleIsoInterFoam and PLICContribution by Henning Scheufler and Johan Roenby. Headers reviewed. Rebased to the latest develop.
1) Implementation of the compressibleIsoInterFOam solver
2) Implementation of a new PLIC interpolation scheme.
3) New tuto...Contribution by Henning Scheufler and Johan Roenby. Headers reviewed. Rebased to the latest develop.
1) Implementation of the compressibleIsoInterFOam solver
2) Implementation of a new PLIC interpolation scheme.
3) New tutorials associated with the solvers
This implementation was carried out by Henning Scheufler (DLR) and Johan
Roenby (DHI), following :
\verbatim
Henning Scheufler, Johan Roenby,
Accurate and efficient surface reconstruction from volume fraction data
on general meshes, Journal of Computational Physics, 2019, doi
10.1016/j.jcp.2019.01.009
\endverbatim
The integration of the code was carried out by Andy Heather and Sergio
Ferraris from OpenCFD Ltd.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/319DEFEATURE: deprecate v2f model in favour of kEpsilonPhitF2020-01-03T09:41:19ZKutalmış BerçinDEFEATURE: deprecate v2f model in favour of kEpsilonPhitF- kEpsilonPhitF is a kEpsilon-based model which originated
from (Durbin, 1995)’s v2-f methodology. However, the majority of
v2-f model variants proved to be numerically stiff for segregated
solution algorithms due to the coup...- kEpsilonPhitF is a kEpsilon-based model which originated
from (Durbin, 1995)’s v2-f methodology. However, the majority of
v2-f model variants proved to be numerically stiff for segregated
solution algorithms due to the coupled formulations of v2 and f fields,
particularly on wall boundaries.
The v2-f variant (i.e. OpenFOAM’s v2f model) due to
(Lien and Kalitzin, 2001) reformulated the original v2-f model to enable
segregated computations; however, a number of shortcomings regarding
the model fidelity were reported in the literature.
To overcome the shortcomings of the v2-f methodology, the v2-f approach
was re-evaluated by (Laurence et al., 2005) by transforming v2 scale into
its equivalent non-dimensional form, i.e. phit, to reduce the numerical
stiffness.
This variant, i.e. kEpsilonPhitF, is believed to provide numerical
robustness, and insensitivity to grid anomalies while retaining the
theoretical model fidelity of the original v2-f model.
Accordingly the v2f RANS model is deprecated in favour of the variant
kEpsilonPhitF model.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/348DOC: Elaborate the usage of function objects2020-06-08T14:44:34ZKutalmış BerçinDOC: Elaborate the usage of function objects### Summary
Documentation and usage examples are limited for some of the function objects. This somewhat hampers the efforts of users to access all capabilities of them.
Therefore, we decided to elaborate the usage of function obje...### Summary
Documentation and usage examples are limited for some of the function objects. This somewhat hampers the efforts of users to access all capabilities of them.
Therefore, we decided to elaborate the usage of function objectcs in:
- Extended Code Guide (comprises the full spectrum of details)
- Header files (comprises the minimal set of info, directing the users to the central info hub, the Extended Code Guide)
In parallel to the `Extended Code Guide` improvements (corresponding: [Extended Code Guide:doc-FOs-part-1](https://develop.openfoam.com/Documentation/Extended-Code-Documentation/tree/doc-FOs-part-1)), it is useful:
- to provide a minimal documentation in the header files of the function objects
- to provide at least one example of usage per function object in tutorials
In addition, style/implementation consistency across function objects can be imposed for:
- update libs of etc/caseDicts/postProcess items
- ensure `destructor=default`
- ensure `no copy construct`/`no copy assignment`
- static data members
- ensure constness
- change `lookupOrDefault()` to `getOrDefault()`
### Resolved bugs
#1594
### Risks
Considerably low.
Regression tests are pending.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/361DOC: Elaborate the usage of topoSet2020-06-08T14:52:12ZKutalmış BerçinDOC: Elaborate the usage of topoSet### Summary
Documentation and usage examples for `topoSet` are considerably improved.
### Risks
Considerably low.### Summary
Documentation and usage examples for `topoSet` are considerably improved.
### Risks
Considerably low.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/370DOC-STYLE: various release changes2020-06-16T12:50:23ZKutalmış BerçinDOC-STYLE: various release changes- Header-file documentation of various new functionalities was moved to the Extended Code Guide.
- Various corrections to the clashes in release commits #1726- Header-file documentation of various new functionalities was moved to the Extended Code Guide.
- Various corrections to the clashes in release commits #1726v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/352Enabled postProcess on film region for reactingParcelFoam2020-03-27T09:35:53ZAndrew HeatherEnabled postProcess on film region for reactingParcelFoamThis change enables function objects to be executed on the film region using the postProcess utility/option.
Cross-ref EP 1105
@PrashantThis change enables function objects to be executed on the film region using the postProcess utility/option.
Cross-ref EP 1105
@Prashantv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/356ENH: add directionalMeshWave functionality2020-04-30T10:32:17ZKutalmış BerçinENH: add directionalMeshWave functionality### Summary
For a given point within a given mesh, the existing `meshWave` method gives
the orthogonal distance to a patch. In meshes with very steep terrain (e.g.
a hill of 90 [deg]), this might be problematic for the fields th...### Summary
For a given point within a given mesh, the existing `meshWave` method gives
the orthogonal distance to a patch. In meshes with very steep terrain (e.g.
a hill of 90 [deg]), this might be problematic for the fields that require
the distance to the patch associated with the terrain surface.
`directionalMeshWave` is a variant of `meshWave` distance-to-patch method,
which ignores the component in the specified direction. Can be used e.g. to
calculate the distance in the z-direction only.
Requirement by CENER
Implementation by Mattijs Janssens
### Resolved bugs (If applicable)
None
### Details of new models (If applicable)
##### meshWave
![wallDistance_meshWave](/uploads/354fa2b0bc3c76b5beeb7cd5966dd204/wallDistance_meshWave.png)
##### directionalMeshWave
![wallDistance_directional](/uploads/d818fa02f4d32c3d4fc98e2c11f14008/wallDistance_directional.png)
### Risks
Nonev2006Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/360ENH: enable user to control re-writing of function object output file headers...2020-11-30T09:54:11ZAndrew HeatherENH: enable user to control re-writing of function object output file headers. See #1556v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/344ENH: improve access to the inner content of turbulence models2020-04-08T10:53:57ZKutalmış BerçinENH: improve access to the inner content of turbulence models~~WIP for `Clang` compilation test.~~ [log.linux64GccDPInt32Opt.zip](/uploads/42d7ada437728c6c6772aca28683ab81/log.linux64GccDPInt32Opt.zip) (Gcc 7.4)
[log.linux64ClangDPInt32Opt.zip](/uploads/92ba2973af16077b4f17197e0a385ae9/log.linux6...~~WIP for `Clang` compilation test.~~ [log.linux64GccDPInt32Opt.zip](/uploads/42d7ada437728c6c6772aca28683ab81/log.linux64GccDPInt32Opt.zip) (Gcc 7.4)
[log.linux64ClangDPInt32Opt.zip](/uploads/92ba2973af16077b4f17197e0a385ae9/log.linux64ClangDPInt32Opt.zip) (LLVM 9.0)
[testLoopReport.PASS.zip](/uploads/b65f5e0e1a43e1608e2ed96aee84a2cc/testLoopReport.zip)
### Summary
The commits provide access to:
- `omega` field estimations for non-omega turbulence models,
- model coefficients of turbulence models for `fvOptions`.
### Resolved bugs (If applicable)
n/a
### Details of new models (If applicable)
n/a
### Risks
- No change to the current behaviourv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/342ENH: improve analytic eigen for small off-diagonals2020-02-28T10:50:51ZKutalmış BerçinENH: improve analytic eigen for small off-diagonals~~WIP for `Clang9` scratch-compilation.~~
### Summary
The analytic eigendecomposition methods were further improved and tested for **small off-diagonal entries**.
Numerical diagonalisation of 2x2 or 3x3 matrices with analytic me...~~WIP for `Clang9` scratch-compilation.~~
### Summary
The analytic eigendecomposition methods were further improved and tested for **small off-diagonal entries**.
Numerical diagonalisation of 2x2 or 3x3 matrices with analytic methods are, like the methods currently being used in OpenFOAM, inherently error prone. **Despite its speed, the analytic methods may becomes inaccurate or may even fail completely if the matrix entries differ greatly in magnitude, particularly with large off-diagonal elements.**
Accordingly, there will always be a combination of value-set that the considerably improved eigendecomposition suite will fail.
The remedy is to sacrifice the speed by using iterative methods (like LAPACK, GNU-Sci, MATLAB, NumPy etc. etc. no matter what the size of matrix is), or hybrid analytic/iterative methods like the publication below: (Kopp, 2008) arXiv.org: physics/0610206 https://www.mpi-hd.mpg.de/personalhomes/globes/3x3/index.htm
Might to consider to look for funding to incorporate such slow-yet-more-stable methods for small eigendecompositions.
Otherwise, we will need to live with it, I'm afraid, by covering the corner cases as they appear in the course of time.
### Caveats
- Will always be a value-set combination for eigendecompositions will fail
- Single- or mixed-precision computation of eigendecompositions will likely and noisily fail as double-precision computation was the only intention
### Tests
`Clang9` = `PASS`: [log.linux64ClangDPInt32Opt.gz](/uploads/534036a6b4c3ff6697f9c1dc4def9725/log.linux64ClangDPInt32Opt.gz) with HEAD~1 = `a456e9ae92 - (origin/develop, develop)`
`Alltest-TUT` = `PASS`: [testLoopReport.gz](/uploads/4a7f88dc4179df5b57a6e487379a116e/testLoopReport.gz)
The logs of the below were not attached due to their sizes, yet the return log was given.
`Test-SymmTensor` = `PASS`: `#### Passed all 10010170 tests #### `
`Test-SymmTensor2D` = `PASS`: `#### Passed all 1260123 tests ####`
`Test-Tensor` = `PASS`: `#### Passed all 8030254 tests ####`
`Test-Tensor2D` = `PASS`: `#### Passed all 4380204 tests ####`v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/354ENH: Improve and verify atmBoundaryLayerInlet conditions2020-06-05T13:42:24ZKutalmış BerçinENH: Improve and verify atmBoundaryLayerInlet conditions### Summary
- Related to the log-law type ground-normal inflow boundary conditions for
wind velocity and turbulence quantities for homogeneous, two-dimensional,
dry-air, equilibrium and neutral atmospheric boundary layer (ABL) m...### Summary
- Related to the log-law type ground-normal inflow boundary conditions for
wind velocity and turbulence quantities for homogeneous, two-dimensional,
dry-air, equilibrium and neutral atmospheric boundary layer (ABL) modelling
- ENH: Generalises Richards-Hoxey expressions. This allows to input experimental profiles or heuristic spatial-variant profiles in a mathematically consistent way.
Yang, Y., Gu, M., Chen, S., & Jin, X. (2009).
New inflow boundary conditions for modelling the neutral equilibrium
atmospheric boundary layer in computational wind engineering.
J. of Wind Engineering and Industrial Aerodynamics, 97(2), 88-95.
DOI:10.1016/j.jweia.2008.12.001
- ENH: Adds new generalised `atmBoundaryLayerInletOmega` boundary condition by using:
Yang, Y., Gu, M., & Jin, X., (2009).
New inflow boundary conditions for modelling the
neutral equilibrium atmospheric boundary layer in SST k-ω model.
In: The Seventh Asia-Pacific Conference on Wind Engineering,
November 8-12, Taipei, Taiwan.
- ENH: Adds new verification case `tutorials/verificationAndValidation/atmosphericFlows/HargreavesWright_2007` by using:
Rectangular prism shown in FIG 1 of
Hargreaves, D. M., & Wright, N. G. (2007).
On the use of the k–ε model in commercial CFD software
to model the neutral atmospheric boundary layer.
Journal of wind engineering and
industrial aerodynamics, 95(5), 355-369.
DOI:10.1016/j.jweia.2006.08.002
Benchmark data:
HW, 2007 FIG 6
- BUG: Fixes value-entry behaviour in `atmBoundaryLayerInlet` (fixes #1578) (Thanks to @perjorgensen for the bug report).
- Without this change:
- for serial-parallel computations, if `value` entry is available in
an `atmBoundaryLayerInlet` BC, the theoretical ABL profile expressions
are not computed, and the `value` entry content is used as a profile data
- for parallel computations, if `value` entry is not available, `decomposePar`
could not be executed.
- With this change:
- assuming `value` entry is always be present, the use of `value` entry for
the ABL profile specification is determined by a flag `initABL`
- the default value of the optional flag `initABL` is `true`, but whenever
`initABL=true` is executed, `initABL` is overwritten as `false` for the
subsequent runs, so that `value` entry can be safely used.
- BUG: Ensures `atmBoundaryInlet` conditions are Galilean-invariant (fixes #1692)
- DOC: Improves `atmBoundaryLayerInlet` header documentation
### Resolved bugs (If applicable)
#1578
#1692
### Details of new models (If applicable)
##### kEpsilon-parallelHierarchical8-Gcc74DP:
![Ux_upstream](/uploads/8586589de26be6cbf33602f420b1872d/Ux_upstream.png)
![Ux_mid](/uploads/e89a57641ff4799d90e60b760bac2cb8/Ux_mid.png)
![Ux_downstream](/uploads/5227ff27d82ad807ed12b216f4d8d87e/Ux_downstream.png)
![epsilon](/uploads/75d3f250399b9ecd27ccab11f424299c/epsilon.png)
![k](/uploads/9796779be6eebebdc8ac92ec22e3335f/k.png)
##### kOmegaSST-parallelHierarchical8-Gcc74DP:
![Ux_upstream](/uploads/4a7d7c94ea8b5a3147b16d0b05013be4/Ux_upstream.png)
![Ux_mid](/uploads/be83cc10455335ae3c85f9237fc1e489/Ux_mid.png)
![Ux_downstream](/uploads/1f31d8d2ef9872f4be0ac0dba5e8234b/Ux_downstream.png)
![k](/uploads/ecbebd53a4c6614877dece10e61f2a71/k.png)
![omega](/uploads/0420c6c1d4637f756d92992b7f884568/omega.png)
### Risks
##### Regression
Bitwise regression is preserved.
##### Changes to user input
- `zGround` is silently deprecated, and its functionality is now inherently computed.
- `d` is introduced for `displacement height`.
- ~~`Uref` and `Zref` are noisily deprecated:~~
- ~~`Uref` is renamed as `uRef` since it refers to a scalar rather than a vector `U`.~~
- ~~`Zref` is renamed as `zRef` since it was always a scalar.~~
### Future work
- These inlet conditions are limited to the surface layer portion of the atmospheric boundary layer:
- Neutral-stratified
- Dry-air
- No Ekman layer
- These inlet conditions can/should be generalised to stable/unstable stratification as well as into the Ekman layer since neutral conditions are **very rare**.
- Spatial variation in input of aerodynamic roughness length, `z0`, and displacement height, `d`.
- Further consistent boundary conditions are required to improve the verification case in terms of `nut` predictions for
- Top boundaries
- Ground boundariesv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/340ENH: Improve polynomial equations and analytical eigendecompositions2020-02-18T17:31:35ZKutalmış BerçinENH: Improve polynomial equations and analytical eigendecompositions### Summary
Analytical eigendecomposition routines show irregular numerical instabilities particularly for cases wherein off-diagonal elements of a tensor involve noise. The issue revealed to be caused by the polynomialEqn containers,...### Summary
Analytical eigendecomposition routines show irregular numerical instabilities particularly for cases wherein off-diagonal elements of a tensor involve noise. The issue revealed to be caused by the polynomialEqn containers, particularly `cubicEqn`.
In addition, the analytical eigendecomposition routines seem to be mathematically inconsistent since tensors are not allowed to return complex types, which is nevertheless the norm for asymmetric matrices.
Accordingly, this set of commits aims to improve the numerical stability of analytical eigendecompositions, and to provide a group of verification tests to prevent future breaks in the workflow.
[unit-test-notebooks-17-Feb-20.zip](/uploads/bd21eee046e249f3ae4830537472e625/unit-test-notebooks-17-Feb-20.zip)
### Resolved bugs
#1311 #1312 #1527 #1575 #1596
### Risks
Low.
`polynomialEqns` and analytical eigendecomposition routines were considerably isolated from the rest of the code.
@markv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/355ENH: Injection models - added entry to ignore injection positions outside of ...2020-05-15T08:29:35ZAndrew HeatherENH: Injection models - added entry to ignore injection positions outside of the meshInjection models: added option to ignore injection locations that are out-of-bounds (outside of the domain)
Example in the injection model input dictionary:
// New entry to ignore injections out of bounds
ignoreOutOfBounds yes;Injection models: added option to ignore injection locations that are out-of-bounds (outside of the domain)
Example in the injection model input dictionary:
// New entry to ignore injections out of bounds
ignoreOutOfBounds yes;v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/364ENH: Miscellaneous enhancement/features and bug fixes2020-06-11T12:30:36ZKutalmış BerçinENH: Miscellaneous enhancement/features and bug fixesv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/363ENH: New atmospheric boundary layer (ABL) model suite (Part 1)2020-06-09T10:09:12ZKutalmış BerçinENH: New atmospheric boundary layer (ABL) model suite (Part 1)### Summary
This commit is the first main commit of a collaborative work between `OpenCFD Ltd.`-`ENERCON Gmbh`-`CENER`, for which there will be another comprehensive commit in the next release (may include SOWFA-6 - [see](https://gith...### Summary
This commit is the first main commit of a collaborative work between `OpenCFD Ltd.`-`ENERCON Gmbh`-`CENER`, for which there will be another comprehensive commit in the next release (may include SOWFA-6 - [see](https://github.com/NREL/SOWFA-6/issues/11) for exchange of ideas).
With this commit, OpenFOAM learns:
- How to comprehensively model (RANS) surface and Ekman atmosphere layers under (slightly/very) stable/unstable/neutral atmospheric stability conditions over spatiotemporal-variant terrain (e.g. partially forestry plain).
### Details
Please refer to the header file documentation for complete set of details.
- 8 new `fvOption`s that are usable with epsilon/omega-based RANS closure models:
- atmAmbientTurbSource
- atmBuoyancyTurbSource
- atmCoriolisUSource
- atmLengthScaleTurbSource
- atmPlantCanopyTurbSource
- atmPlantCanopyUSource
- atmPlantCanopyTSource
- atmNutSource
- 7 new `wall function`s shipped with `PatchFunction1` and `TimeFunction1` support for the input entries:
- atmAlphatkWallFunction
- atmEpsilonWallFunction
- atmNutkWallFunction
- atmNutUWallFunction
- atmNutWallFunction
- atmOmegaWallFunction
- atmTurbulentHeatFluxTemperature
- A new function object to quantify the [Obukhov length](http://glossary.ametsoc.org/wiki/Obukhov_length#:~:text=Obukhov%20length,consumption%20of%20turbulence%20kinetic%20energy.):
- ObukhovLength
- 3 new tutorials involving `buoyantBoussinesqSimpleFoam` verifications in comparison to field measurements:
- `verificationAndValidation/atmosphericFlows/atmFlatTerrain`
- verification with the `Leipzig` field experiment
- illustration of precursor/successor field mapping
- `verificationAndValidation/atmosphericFlows/atmForestStability`
- verification with the Sweden field experiment
- 2 new actuator disk modelling approaches in the existing `actuationDiskSource` wherein the incoming velocity measurements can now be held by using `topoSet`s.
### Resolved bugs (If applicable)
None.
### Verifications
The model suite was verified for `neutral stability` by the `Leipzig` experiment for which all the details can be found in, and can be reproduced by `verificationAndValidation/atmosphericFlows/atmFlatTerrain`
`buoyantBoussinesqSimpleFoam-kEpsilon`:
<img src="/uploads/96349ecee9d1561d196795b266d22cdd/u-z.png" width="250" height="500">
<img src="/uploads/146d8921d130e210f27b21f1c8a902ce/v-z.png" width="250" height="500">
`buoyantBoussinesqSimpleFoam-kOmegaSST`:
<img src="/uploads/aead7fafb086e2d918302d45660e8e61/u-z.png" width="250" height="500">
<img src="/uploads/bca10f4506b06986ed47c2114e9c43ad/v-z.png" width="250" height="500">
In addition, the model suite was verified for all spectrum of stability conditions with forestry ground by the `Sweden(?)` experiment for which all the details can be found in, and can be reproduced by `verificationAndValidation/atmosphericFlows/atmForestStability`
`buoyantBoussinesqSimpleFoam-kEpsilon` (wind speed, turbulent kinetic energy, and wind veer profiles, respectively):
<img src="/uploads/370aca91fc19f2fbb719ce4655ad4618/uNorm-zNorm.png" width="600" height="500">
<img src="/uploads/e024e77ee5460299774ccaeff9e360c5/kNorm-zNorm.png" width="600" height="500">
<img src="/uploads/d292e5901e01dbb0bc517d9c76be79b2/veer-zNorm.png" width="600" height="500">
with the Obukhov lengths:
veryStable = 44.7979
stable = 300.723
slightlyStable = 859.962
neutral = undefined
slightlyUnstable = -547.088
unstable = -265.992
`buoyantBoussinesqSimpleFoam-kOmegaSST` (wind speed, turbulent kinetic energy, and wind veer profiles, respectively):
<img src="/uploads/4e19e3e02e97044e8d2dda9e718e2e32/uNorm-zNorm.png" width="600" height="500">
<img src="/uploads/8803c8bbe63de1ac2015310615521fa2/kNorm-zNorm.png" width="600" height="500">
<img src="/uploads/c938b5ae2d5fd19e5116bd00b910809a/veer-zNorm.png" width="600" height="500">
with the Obukhov lengths:
veryStable = 67.5555
stable = 396.562
slightlyStable = 1147.69
neutral = undefined
slightlyUnstable = -707.885
unstable = -319.368
Furthermore, the persistence of atmospheric boundary layer inlet profiles downstream were quantified in comparison to the profiles near the outlet, and it was found out that the overall discrepancy is within 2%:
(wind speed, turbulent kinetic energy, turbulence intensity, and temperature horizontal profiles, respectively)
<img src="/uploads/e01e5f6429cb054adda7bddc649d4348/Horizontal_MagU.png" width="600" height="500">
<img src="/uploads/78472b8205b8c79a611793a9b0a6933a/Horizontal_k.png" width="600" height="500">
<img src="/uploads/f001568734ac5b398018ba1fd5349aa2/Horizontal_TI.png" width="600" height="500">
<img src="/uploads/21eaa5b3ec305eacb8f2af11c0226985/Horizontal_T.png" width="600" height="500">
### Risks
- **User input change:** `nutkAtmRoughWallFunction` is renamed without extra support to `atmNutkWallFunction` (ensured the bitwise regression)
- Since the majority of the utilities above are new, the potential effects on the existing utilities would only be unexpected.
v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/350ENH: New wall-function blending approaches2020-06-17T15:26:52ZKutalmış BerçinENH: New wall-function blending approaches### Summary
This merge request is a discussion placeholder for two topics:
- ~~Potential improvements to the wall-function hierarchies~~
- Wall-function blending treatments between viscous and inertial sublayers
##### ~~Wall-func...### Summary
This merge request is a discussion placeholder for two topics:
- ~~Potential improvements to the wall-function hierarchies~~
- Wall-function blending treatments between viscous and inertial sublayers
##### ~~Wall-function hierarchy~~
~~Arguably, the wall-function hierarchies need a reexamination as the relations have "grown organically" in the course of time. One recent problem is that `{omega,epsilon,k}Wall` functions use data members from `nutWallFunction` base class even though the former group is not derived from the latter.~~
~~One practical consequence is that `{omega,epsilon,k}Wall` always require a `nut` wall function is defined in the `nut` dictionary, otherwise simulation in question noisily fails without informing the user with useful information, e.g. [CFD-Online:Error with k-omega SST and simpleFoam (21-Feb-20)](https://www.cfd-online.com/Forums/openfoam-solving/224476-error-k-omega-sst-simplefoam.html), and the bug-fix:55776069975061c488a6294a5e81a7a92b04db45.~~
##### Wall-blending treatments
- Four wall-function blending treatments were introduced:
- `STEPWISE`
- `MAX`
- `BINOMIAL`
- `EXPONENTIAL`
- .. For the following wall functions:
- `epsilonWallFunction`
- `omegaWallFunction`
- `nut{k,U}WallFunction`
- The header-file documentations were improved for the following wall functions for which the blending treatments were not applicable (e.g. due to the continuous treatment in `nutUSpaldingWallFunction`):
- `nutU{Spalding,Tabulated,Blended}WallFunction`
- `nut{k,U}RoughWallFunction`
- `nutLowReWallFunction`
- `{kLowRe,kqR}WallFunction`
- Based on:
- Viegas and Rubesin (1983); Viegas et al. (1985) (i.e. the option: `STEPWISE`)
- Menter and Esch (2001) (i.e. the option: `BINOMIAL`)
- Popovac and Hanjalić (2007) (i.e. the options: `MAX`, `EXPONENTIAL`)
- Knopp et al. (2006) (i.e. the option: `TANH` only for `omega`)
### Resolved bugs
N/A
### Risks
High risk, yet bitwise backward compatibility, and regression were verified for each modified functionality.
@mark @Sergio @Mattijs v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/371ENH: prevent natural-logarithm domain errors in nut wall functions2020-06-18T20:57:08ZKutalmış BerçinENH: prevent natural-logarithm domain errors in nut wall functions#1730#1730v2006Andrew HeatherAndrew Heather