openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2023-06-15T12:34:19Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/610ENH: specularRadiation: add axisymmetric fvDOM boundary condition2023-06-15T12:34:19ZKutalmış BerçinENH: specularRadiation: add axisymmetric fvDOM boundary condition#### Problem
The `fvDOM` radiation model of OpenFOAM is not
applicable to axisymmetric geometries, resulting
in:
- Increased computational costs,
- Complicated mesh generation,
- Reduced numerical stability.
#### Solution
Implement an...#### Problem
The `fvDOM` radiation model of OpenFOAM is not
applicable to axisymmetric geometries, resulting
in:
- Increased computational costs,
- Complicated mesh generation,
- Reduced numerical stability.
#### Solution
Implement and verify the axisymmetric `fvDOM`
boundary condition elaborated in:
- Kumar, P., & Eswaran, V. (2013). A methodology to
solve 2D and axisymmetric radiative transfer
problems using a general 3D solver. Journal of
heat transfer, 135(12).
#### Verification
Based on:
- Cai, J., & Modest, M. F. (2016). Specular reflective boundary conditions for Discrete Ordinate
Methods in Periodic or Symmetric Geometries. In Journal of Physics: Conference Series (Vol. 676, No. 1, p. 012002). IOP Publishing.
<img src="/uploads/6a1efc2fadb73e5baa91128df402be99/Screenshot_from_2023-06-02_14-32-25.png" width="40%" height="40%">
#### Risks
- No change in existing input/output.
- The predictions of the condition for the radial heat flux distribution on walls need to be improved.
#### Metadata
- Related: #855
- [x] linux64ClangDPInt32Opt (clang13)
- [ ] linux64GccDPInt32Opt
- [ ] linux64GccSPDPInt64Debug
- [x] Alltest: No new error/No change in existing output
- [x] Test cases: [MR610-02Jun2023-test.zip](/uploads/8f026406462b83fecce9b6bca36c4535/MR610-02Jun2023-test.zip)v2306Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/559ENH: sorptionWallFunction: new wall boundary condition2022-09-07T13:58:40ZKutalmış BerçinENH: sorptionWallFunction: new wall boundary condition**Summary**
- Implementation of a sorption wall-function boundary condition for an arbitrary operand scalar in line with:
- [Foat et al. (2022). Predicting vapour transport from semi-volatile organic compounds concealed within permea...**Summary**
- Implementation of a sorption wall-function boundary condition for an arbitrary operand scalar in line with:
- [Foat et al. (2022). Predicting vapour transport from semi-volatile organic compounds concealed within permeable packaging.](https://doi.org/10.1016/j.ijheatmasstransfer.2021.122012)
- [Foat (2021). Modelling vapour transport in indoor environments for improved detection of explosives using dogs.](https://eprints.soton.ac.uk/456709/)
- New condition: `sorptionWallFunction`
- The `sorptionWallFunction` is a wall boundary condition to specify scalar/concentration gradient for turbulent and laminar flows.
- Blending options:
- Stepwise (discontinuous) (Foat (2021) - (Eq. 5.3))
- Exponential (smooth) (Foat et al. (2022) - (Eqs. 1-6))
- Binomial (smooth)
- Tanh (smooth)
- Max (discontinuous)
**Theory**
<img src="/uploads/4c0398ea8f0fab2d22f2394c3eb39c98/Screenshot_from_2022-08-19_11-46-39.png" width="75%" height="75%">
### Meta-data
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorAndrew 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/531ENH: outletMappedUniformInlet: add multiple fraction, offset and time delays2022-04-29T20:00:23ZKutalmış BerçinENH: outletMappedUniformInlet: add multiple fraction, offset and time delays### Summary
**Aim**
To implement a recirculation boundary
condition for an arbitrary operand scalar with:
- Multiple connected outlets and inlets
- Optional filtration fraction for each recirculation
loop
- Optional time delay for eac...### Summary
**Aim**
To implement a recirculation boundary
condition for an arbitrary operand scalar with:
- Multiple connected outlets and inlets
- Optional filtration fraction for each recirculation
loop
- Optional time delay for each recirculation loop
Additionally, write-control of `scalarTransport` was transferred from `controlDict` to the function object, and enabled `UList` parameters in `interpolateXY` for wider applications.
**Previous status**
Existing boundary condition: `outletMappedUniformInlet`
- Connected between a single outlet and a single inlet
- Instantaneous recirculation: no outlet-to-inlet time delay
- Optional filtration fraction is available as a constant value
- Optional offset is available as a constant value
**Improvements**
- Arbitrary number of outlets can be connected to a single inlet
- Each inlet can be connected to different and arbitrary
combination of outlets
- Each outlet-inlet connection has:
- Optional filtration fraction as a Function1 type
- Optional offset as a Function1 type (i.e. adding/substracting a substance)
- Optional time delay (from outlet to inlet) as a Function1 type
- Each inlet has an optional base inlet-field as a PatchFunction1 type
**Theory**
<img src="/uploads/5cd45d1e0a12a12011aa090361fa16ba/image.png" width="50%" height="50%" />
**Usage**
<img src="/uploads/d6b9aa06465e479f2fcbae6ea92f84e2/image.png" width="75%" height="75%" />
### Resolved bugs
N/A
### Methodology
**Remarks**
- Difficult to design a simple verification test case due to the amount of data
- Verifications were carried out heuristically and manually
- No validation/benchmark available
**Tests**
- Cases
- Single-outlet single-inlet, pisoFoam-LES, constant time-step: [1-single-outlet-inlet.zip](/uploads/bfe8ee7572c24cde5ccd4cb555d9b9d3/1-single-outlet-inlet.zip)
- Multiple-outlet multiple-inlet, pisoFoam-LES, constant time-step: [2-multiple-outlet-inlet.zip](/uploads/dd2b892e86e2b39f829f6189a060b23b/2-multiple-outlet-inlet.zip)
- Multiple-outlet multiple-inlet, reactingParcelFoam-RANS, adjustable time-step
- Scenarios
- Single/multiple-processor run
- Single/multiple-processor run with restart
- decomposePar
- reconstructPar
- redistributePar –decompose
-redistributePar -reconstruct
- No collated-format tests
- Only scalar fields
### Discussion
- No inlet-inlet connection
- Could not infer any necessity for an inlet-inlet
connection. Happy to be proven incorrect, however.
- No constraints were put onto the input entries;
therefore, users need to use their attention
and engineering judgements to avoid
potential unphysical results
- Except negative input of time delays are
suppresed to be zero without emitting any
warning messages.
- For example, filtration fraction can be set to
any number (e.g. more than 100%)
- Needs extensive tests to assume the
functionalities safe for any single-phase,
multiphase and overset finite-volume
applications.
### Meta-data
EP#1730
* [x] Clean compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/499Function1 objectRegistry access2022-02-25T06:53:57ZAndrew HeatherFunction1 objectRegistry access### Summary
Cross reference [EP 1657](https://exchange.openfoam.com/node/1657)
### Details of new models
Function1's
- `Function1` : The Function1 class can now be created using an `objectRegistry`, i.e. mesh or time databases, allow...### Summary
Cross reference [EP 1657](https://exchange.openfoam.com/node/1657)
### Details of new models
Function1's
- `Function1` : The Function1 class can now be created using an `objectRegistry`, i.e. mesh or time databases, allowing other registered objects to be retrieved, e.g. fields, models, function object state and results information
- change propagated across all `Function1` instances, e.g. boundary conditions, function objects, other `Function1s`
- `functionObjectValue` : set the `value` according to the result of a function object
- `sample` : set the `value` according to a field value
- `limitRange` : renamed to `inputValueMapper` and extended to include operations using function object results
Function object updates
- `sampledSets` : extended to store the set `min`, `max` and `average` values in its results dictionary
- `reference` : the reference value `refValue` is now set according to a `Function1` type. To recover the old behaviour (sampling a field value) users can employ the new `sample` Function1 type.
- registered fields are now prefixed - typically by `<function_object_name>:` - to avoid name collisions on registration, e.g. you can now have multiple `fieldAverage` function objects that act on the same field
Test case
- `$FOAM_TUTORIALS/incompressible/simpleFoam/simpleCar`
- Sample the pressure field using a `sets` function object; the result `average(p)` is created.
- The sample `average(p)` value is supplied to a `valueAverage` function object to perform time averaging. This creates the result `average(p)Mean`.
- The `reference` function object's `refValue` makes use of the new `functionObjectValue` Function1, where the value `average(p)Mean` is retrieved from the `average1` function object to determine the final reference field.
- A second `reference` function object to shows how to recover the old function object behaviour.
### Risks
Testing required
- `TimeFunction1` has been deprecated
- check that previous behaviours are maintained, e.g. for lagrangian injection models when using `engineTime`v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/486ENH: Improve the handling of wall-function coefficients and blenders2022-05-18T16:05:21ZKutalmış BerçinENH: Improve the handling of wall-function coefficients and blenders### Summary
- Fixes #1457 and #1966
- Improves the handling of wall-function coefficients and blenders
- Standardises the output of wall-function entries
- Removes redundant and inconsistent virtual specifiers
- Modernises the code sty...### Summary
- Fixes #1457 and #1966
- Improves the handling of wall-function coefficients and blenders
- Standardises the output of wall-function entries
- Removes redundant and inconsistent virtual specifiers
- Modernises the code style
- Improves header file documentation
- Removes the blending option `BINOMIAL2` from `omegaWallFunction`
### Resolved bugs
Closes #1457, #1966
### Risks
- Silently replaces the **default** blending option `BINOMIAL2` of the `omegaWallFunction` with the option `BINOMIAL` with `n=2`. In theory, both expressions are the same. Yet numerically, both expressions will yield negligible differences in floating-point decimals.
### 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
- [x] Verification: No change in output [rhoSimpleFoam/simpleFoam/buoyantBoussinesqSimpleFoam](https://develop.openfoam.com/OpenCFD/OpenFOAM-test/-/tree/test-wall-functions/tests-for-v2206/regressions-wall-functions)v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/467ENH: Added under-relaxation to jump conditions2021-06-14T15:34:44ZAndrew HeatherENH: Added under-relaxation to jump conditionsUpdates to the jump boundary conditions
- provide an optional minimum jump value
```
plane
{
type fan;
patchType cyclic;
jump uniform 0;
value uniform 0;
...Updates to the jump boundary conditions
- provide an optional minimum jump value
```
plane
{
type fan;
patchType cyclic;
jump uniform 0;
value uniform 0;
uniformJump false;
jumpTable ( (1000 0) (-200 1) (20 2) (-0.75 3) );
// Optional minimum jump value
minJump 0;
}
```
- add possibility to under relax the jump value. Currently only applied to the fanFvPatchField where it can be useful for steady, non-uniform jump set-ups to avoid instabilities/checker-boarding, e.g.
```
plane
{
type fan;
patchType cyclic;
jump uniform 0;
value uniform 0;
uniformJump false;
// Optional under-relaxation
relax 0.2;
...
}
```
Current (old) behaviour
![noRelax-minJump-GREAT](/uploads/47d41219028e2705ac296c9a0e3d513d/noRelax-minJump-GREAT.png)
New behaviour with under-relaxation
![relax0dot2-minJump-GREAT](/uploads/ccbf2edf3627bd960dd9bd6419815f5e/relax0dot2-minJump-GREAT.png)v2106Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/456Support AMI for multi-world operation2021-05-26T08:27:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comSupport AMI for multi-world operation### Summary
Multi-world operation now supports AMI (`nearestPatchFaceAMI`)
Fixes #2099### Summary
Multi-world operation now supports AMI (`nearestPatchFaceAMI`)
Fixes #2099v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/399ENH: outletMappedUniformInlet: add optional fraction and offset2020-12-16T18:28:32ZKutalmış BerçinENH: outletMappedUniformInlet: add optional fraction and offset### Summary
The new functionality optionally allows the patch-averaged
value to be scaled and/or offset by a pair of specified values.
Example of the boundary condition specification:
```
<patchName>
{
// Mandatory entries...### Summary
The new functionality optionally allows the patch-averaged
value to be scaled and/or offset by a pair of specified values.
Example of the boundary condition specification:
```
<patchName>
{
// Mandatory entries (unmodifiable)
type outletMappedFilterInlet;
outletPatch <outletPatchName>;
// Optional entries (unmodifiable)
fraction 0.1;
offset 10; // (1 0 0);
phi phi;
// Optional (inherited) entries
...
}
```
### Details of new models
**The tutorial `airRecirculationRoom` and related visualisations are exclusively prepared by _Alseny Diallo_**.
![Screenshot_from_2020-12-10_17-22-44](/uploads/0ca11fb914f02e7f7563d0df3e800b07/Screenshot_from_2020-12-10_17-22-44.png)
![Screenshot_from_2020-12-10_18-31-08](/uploads/10d4056dd7bdaed45d29b6e0aaddadc5/Screenshot_from_2020-12-10_18-31-08.png)
![Screenshot_from_2020-12-10_18-17-30](/uploads/83048e2a11c6ace6f8ac13cdf266fd5d/Screenshot_from_2020-12-10_18-17-30.png)
![Screenshot_from_2020-12-10_17-24-11](/uploads/cb9d2e00f334ee41f3ec8e7ff07d6902/Screenshot_from_2020-12-10_17-24-11.png)
![Screenshot_from_2020-12-10_17-24-20](/uploads/38cb29fa995ff837ed520b05c9ab37a6/Screenshot_from_2020-12-10_17-24-20.png)
![Screenshot_from_2020-12-10_17-23-19](/uploads/64a9c92d494ff19cd90e8df1a5b02bc7/Screenshot_from_2020-12-10_17-23-19.png)
![Screenshot_from_2020-12-10_18-09-54](/uploads/40806bc5b100b397998d6e5db55c3e4f/Screenshot_from_2020-12-10_18-09-54.png)
### Risks
- The bug fix may further need to be tested.
- No change to user input.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/398Feature local world2020-12-09T23:42:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comFeature local world### Summary
Coupling (unadapted) different solvers using the 'mapped' boundary conditions. Each solver runs in its own 'world' and the boundary condition specifies the remote 'world' to communicate with. This is in addition to the remot...### Summary
Coupling (unadapted) different solvers using the 'mapped' boundary conditions. Each solver runs in its own 'world' and the boundary condition specifies the remote 'world' to communicate with. This is in addition to the remote region and patch.
### Resolved bugs (If applicable)
(Links to issues)
### Details of new models (If applicable)
All the solver take a new 'world' option to name the simulation. All the 'mapped' type boundary conditions take an additional 'sampleWorld' input to indicate which world to exchange data with. Default is direct exchange so every 'evaluate' needs to be replicated on the other world. Additional there is an indirect exchange which uses a functionObject to do the exchange once per time step. This add additional explicitness but allows running with e.g. different numbers of correctors.
### Risks
(Possible regressions?)
(Changes to user inputs?)
Only affects coupling boundary conditions ('mapped', 'mappedMixed', 'turbulentMappedXXX' etc) so should have no impact apart from that.v2012Andrew 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/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/302ENH: Added new scaledFixedValue boundary condition2019-12-11T10:45:32ZAndrew HeatherENH: Added new scaledFixedValue boundary conditionAdds new `scaledFixedValue` boundary condition
This condition applies a scalar multiplier to the value of another
boundary condition.
Usage
Property | Description | Required | Default value
scale ...Adds new `scaledFixedValue` boundary condition
This condition applies a scalar multiplier to the value of another
boundary condition.
Usage
Property | Description | Required | Default value
scale | Time varing scale | yes |
patch | patchField providing the raw patch value | yes |
Example of the boundary condition specification to scale a reference
velocity of (15 0 0) supplied as a fixedValue by a table of values
that ramps the scale from 0 to 1 over 1 second:
```
<patchName>
{
type scaledFixedValue;
scale table
(
( 0 0)
( 1.0 1.0)
(100.0 1.0)
);
patch
{
type fixedValue;
value uniform (15 0 0);
}
}
```v1912Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/143BugFix: corrected keyword for flowRateInletVelocity BC fixes #5772017-08-30T08:49:53ZPrashant SonakarBugFix: corrected keyword for flowRateInletVelocity BC fixes #577corrected as : volumetricFlowRate instead of volumeFlowRatecorrected as : volumetricFlowRate instead of volumeFlowRatev1712AdminAdmin