openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2020-01-03T09:41:19Zhttps://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/324TUT: misc cleanup in various tutorials2020-01-12T11:10:18ZKutalmış BerçinTUT: misc cleanup in various tutorialsv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/327ENH: shm: support for automatic faceZones2020-01-16T12:22:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: shm: support for automatic faceZones### Summary
Extends meshing of faceZones to allow having multiple faceZones per surface
### Details of new models (If applicable)
Currently a single (explicitly named) faceZone can be specified for a surface. This new function...### Summary
Extends meshing of faceZones to allow having multiple faceZones per surface
### Details of new models (If applicable)
Currently a single (explicitly named) faceZone can be specified for a surface. This new functionality extends it to have a separate faceZone for every region of the surface.
### Risks
The default behaviour has not changed. A new keyword, faceZoneNaming, can switch on the new behaviour. See the new mesh/snappyHexMesh/faceZoneRegions tutorial
v2006Andrew HeatherAndrew Heatherhttps://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/330SUBMODULE: added OpenQBMM submodule - see #15222020-01-25T02:11:02ZAndrew HeatherSUBMODULE: added OpenQBMM submodule - see #1522### Summary
Adds the OpenQBMM library from https://www.openqbmm.org/
OpenQBMM is a suite of solvers to simulate polydisperse multiphase flows using
Quadrature-Based Moment Methods (QBMM).
Main author: Alberto Passalacqua @alber...### Summary
Adds the OpenQBMM library from https://www.openqbmm.org/
OpenQBMM is a suite of solvers to simulate polydisperse multiphase flows using
Quadrature-Based Moment Methods (QBMM).
Main author: Alberto Passalacqua @albertop
### Details of new models (If applicable)
OpenQBMM implements methods to describe polydisperse multiphase flows, from the simplest size evolution of non-inertial particles in a carrier fluid to more complex cases with bubbles in a gas-liquid system and inertial particles in a gas-particle flow. These capabilities are implemented in a suite of solvers, among which:
- `pbeFoam` solves a population balance equation in a single control volume. This solver is useful to test kernel functions in the population balance equation and to solve spatially homogeneous problems. Example cases can be found in OpenQBMM/validation/pbeFoam/ which show the validation cases discussed in E. Madadi-Kandjani, A. Passalacqua, An extended quadrature-based moment method with log-normal kernel density functions, Chemical Engineering Science. 131 (2015) 323–339. https://doi.org/10.1016/j.ces.2015.04.005.
- `pbeTransportFoam` allows a frozen flow field to be used to solve a population balance equation with pre-imposed flow motion. A validation case is available in OpenQBMM/validation/pbeTransportFoam/serraTaylorCouette/ and discussed in A. Passalacqua, F. Laurent, E. Madadi-Kandjani, J.C. Heylmun, R.O. Fox, An open-source quadrature-based population balance solver for OpenFOAM, Chemical Engineering Science. 176 (2018) 306–318. https://doi.org/10.1016/j.ces.2017.10.043.
- `buoyantPbePimpleFoam` allows a transient flow with population balance equation to be modelled.
- `polydisperseBubbleFoam` is a specialized solver for gas-liquid flows with evolution of the bubble size due to coalescence and breakup. Bubbles can have a velocity distribution also accounting for polycelerity, with bubbles with different sizes in the same control volume allowed to have different velocities. Example cases are available in OpenQBMM/validation/polydisperseBubbleFoam/ while the implementation is discussed in the article J.C. Heylmun, B. Kong, A. Passalacqua, R.O. Fox, A quadrature-based moment method for polydisperse bubbly flows, Computer Physics Communications. 244 (2019) 187–204. https://doi.org/10.1016/j.cpc.2019.06.005.
- `denseAGFoam` implements an anisotropic Gaussian model for dense gas-particle flows. Implementation details are discussed in B. Kong, R.O. Fox, A solution algorithm for fluid–particle flows across all flow regimes, Journal of Computational Physics. 344 (2017) 575–594. https://doi.org/10.1016/j.jcp.2017.05.013.
- The solvers in the `velocityDistribitionTransport` implement quadrature-based moment methods for velocity distributions. These methods are suitable to describe disperse flows with non-equilibrium velocity distributions, such as crossing jets of particles or droplets. The `diluteVdfTransportFoam` solver implements the quadrature-based velocity distribution transport algorithm for a disperse phase, not coupled to a carrier fluid. One-way coupling between the disperse phase and the carrier fluid is implemented `oneWayCoupledVdfTransportFoam`. In both solvers, the particle size can evolve in space and time and particles can interact through collisions.
### Risks
Low - added as a submodulev2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/337TUT: cleanup compressible tutorials2020-01-29T21:13:55ZKutalmış BerçinTUT: cleanup compressible tutorialsComplete regression: https://ftpbox.esi-group.com/?u=IDXq6Cpj&p=manSCW6c&path=/logs-cleanup-compressible-tuts.tar.gzComplete regression: https://ftpbox.esi-group.com/?u=IDXq6Cpj&p=manSCW6c&path=/logs-cleanup-compressible-tuts.tar.gzv2006Andrew 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/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/343Feature surface handling2020-03-13T17:19:15ZMark OLESENFeature surface handlingAdjust sampling to avoid triangulation.Adjust sampling to avoid triangulation.v2006Mark OLESENMark OLESENhttps://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/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/351Feature VOF mass models2020-04-20T19:58:34ZSergio FerrarisFeature VOF mass modelsAdding interfaceHeatResistance mass transfer model
1) Add interfaceHeatResistance model to icoReactingMultiphaseInterFoam
This model uses a spread source for the continuity Eq.
It is recommended for cases with good...Adding interfaceHeatResistance mass transfer model
1) Add interfaceHeatResistance model to icoReactingMultiphaseInterFoam
This model uses a spread source for the continuity Eq.
It is recommended for cases with good mesh resolution.
2) Adding iso-surface type of calculation for the interface for
the kineticGasEvaporation model
3) Add switch for option to take into account volume change
New pool evaporation tutorial with heat flux at the bottom. See fig:
![Total_dmdt](/uploads/a470ef35b55a319ba4b5673725c003fa/Total_dmdt.png)
The experimental value is in average 1.2e-4 Kg/s. This tutorial uses the updated model
kineticGasEvaporationv2006Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/347TUT: clean up multiphase tutorials2020-05-07T16:32:26ZKutalmış BerçinTUT: clean up multiphase tutorialsWIP to ensure bitwise regression.
FYI: @Prashant
FYI-relevant to .org files: @mark @albertopWIP to ensure bitwise regression.
FYI: @Prashant
FYI-relevant to .org files: @mark @albertopv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/355ENH: Injection models - added entry to ignore injection positions outside of the mesh2020-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/359Feature build granularity2020-05-19T06:14:08ZMark OLESENFeature build granularity- improvements for building with additional MPI layers
- additional flexibility handling libraries- improvements for building with additional MPI layers
- additional flexibility handling librariesv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/362ENH: unify use of dictionary method names2020-06-03T08:31:01ZMark OLESENENH: unify use of dictionary method names- previously introduced `getOrDefault` as a dictionary _get_ method,
now complete the transition and use it everywhere instead of
`lookupOrDefault`. This avoids mixed usage of the two methods that
are identical in behaviour, makes ...- previously introduced `getOrDefault` as a dictionary _get_ method,
now complete the transition and use it everywhere instead of
`lookupOrDefault`. This avoids mixed usage of the two methods that
are identical in behaviour, makes for shorter names, and promotes
the distinction between "lookup" access (ie, return a token stream,
locate and return an entry) and "get" access (ie, the above with
conversion to concrete types such as scalar, label etc).v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/353ENH: Robust Iterative Eigendecomposition and Parallel Low-Memory Dynamic Mode Decomposition2020-06-05T13:35:59ZKutalmış BerçinENH: Robust Iterative Eigendecomposition and Parallel Low-Memory Dynamic Mode Decomposition### Summary
**New robust solver/container: Iterative eigendecomposition:**
The new iterative eigen decomposition functionality is derived from:
Passalacqua et al.'s OpenQBMM (openqbmm.org/),
which is mostly d...### Summary
**New robust solver/container: Iterative eigendecomposition:**
The new iterative eigen decomposition functionality is derived from:
Passalacqua et al.'s OpenQBMM (openqbmm.org/),
which is mostly derived from JAMA (math.nist.gov/javanumerics/jama/).
**New field function object: Parallel low-memory dynamic mode decomposition:**
STDMD (i.e. Streaming Total Dynamic Mode Decomposition) is a variant of
a data-driven dimensionality reduction method.
STDMD is being used as a mathematical post-processing tool to compute
a set of dominant modes out of a given flow (or dataset) each of which is
associated with a constant frequency and decay rate, so that dynamic
features of a given flow may become interpretable, and tractable.
Among other Dynamic Mode Decomposition (DMD) variants, STDMD is presumed
to provide the general DMD method capabilities alongside economised and
feasible memory and CPU usage.
STDMD and mode-sorting algorithms (tags:K, HRDC, KZ, HWR):
Kiewat, M. (2019).
Streaming modal decomposition approaches for vehicle aerodynamics.
PhD thesis. Munich: Technical University of Munich.
URL:mediatum.ub.tum.de/doc/1482652/1482652.pdf
Hemati, M. S., Rowley, C. W., Deem, E. A., & Cattafesta, L. N. (2017).
De-biasing the dynamic mode decomposition for applied Koopman
spectral analysis of noisy datasets.
Theoretical and Computational Fluid Dynamics, 31(4), 349-368.
DOI:10.1007/s00162-017-0432-2
Kou, J., & Zhang, W. (2017).
An improved criterion to select dominant modes from dynamic mode
decomposition.
European Journal of Mechanics-B/Fluids, 62, 109-129.
DOI:10.1016/j.euromechflu.2016.11.015
Hemati, M. S., Williams, M. O., & Rowley, C. W. (2014).
Dynamic mode decomposition for large and streaming datasets.
Physics of Fluids, 26(11), 111701.
DOI:10.1063/1.4901016
Parallel classical Gram-Schmidt process (tag:Ka):
Katagiri, T. (2003).
Performance evaluation of parallel Gram-Schmidt re-orthogonalization
methods.
In: Palma J. M. L. M., Sousa A. A., Dongarra J., Hernández V. (eds)
High Performance Computing for Computational Science — VECPAR 2002.
Lecture Notes in Computer Science, vol 2565, p. 302-314.
Berlin, Heidelberg: Springer.
DOI:10.1007/3-540-36569-9_19
Parallel direct tall-skinny QR decomposition (tags:BGD, DGHL):
Benson, A. R., Gleich, D. F., & Demmel, J. (2013).
Direct QR factorizations for tall-and-skinny matrices in MapReduce
architectures.
2013 IEEE International Conference on Big Data.
DOI:10.1109/bigdata.2013.6691583
Demmel, J., Grigori, L., Hoemmen, M., & Langou, J. (2012).
Communication-optimal parallel and sequential QR and LU
factorizations.
SIAM Journal on Scientific Computing, 34(1), A206-A239.
DOI:10.1137/080731992
DMD properties:
Brunton S. L. (2018).
Dynamic mode decomposition overview.
Seattle, Washington: University of Washington.
youtu.be/sQvrK8AGCAo (Retrieved:24-04-20)
**New extensive, true-false type unit tests for Matrix classes**
### Resolved bugs (If applicable)
**Improved robustness in Moore-Penrose matrix inverse function**
### Details of new models (If applicable)
**A verification example for STDMD: Two-dimensional steady-inflow cylinder test:**
Left-top = MATLAB (using serial data)
Left-bottom = OpenFOAM (serial)
Right-top = MATLAB (using parallel data)
Right-bottom = OpenFOAM (parallel/8-procs)
![Screenshot_from_2020-04-24_16-05-10](/uploads/07ba4e4cbefa9307b69a912958c06180/Screenshot_from_2020-04-24_16-05-10.png)
![Screenshot_from_2020-04-24_16-05-18](/uploads/ad0cbf546bef5091d9049a8869ae2169/Screenshot_from_2020-04-24_16-05-18.png)
![Screenshot_from_2020-04-24_16-05-26](/uploads/844e40652c4a1b3e7ff2e78f4e513e98/Screenshot_from_2020-04-24_16-05-26.png)
### Risks
- STDMD is in its **beta** phase; therefore, small-to-medium changes in input/output interfaces and internal structures should be expected in the next versions depending on the unknown
- Peer-review, or any type of feedback for any part of the code is more than welcomed:
- STDMD internal structure, and IO @mark @andy
- Eigendecomposition @albertop
- Low risk to the existing code status.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/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 Heather