openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2019-01-31T17:00:02Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/231Function object updates2019-01-31T17:00:02ZAdminFunction object updatesRenamed the `residuals` function object to `solverInfo` since it now generates:
* residual fields
* solver type
* initial residual
* final residual
* number of solver iterations
* convergecnce flag
Added new `continuityError` function ...Renamed the `residuals` function object to `solverInfo` since it now generates:
* residual fields
* solver type
* initial residual
* final residual
* number of solver iterations
* convergecnce flag
Added new `continuityError` function object. Example usage:
continuityError1
{
type continuityError;
libs ("libfieldFunctionObjects.so");
...
writeToFile yes;
log yes;
phi phi;
}
\endverbatimv1906AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/235Digital-Filter Based Synthetic Turbulence Generation Method for LES/DES Inflow2019-06-21T12:10:50ZKutalmış BerçinDigital-Filter Based Synthetic Turbulence Generation Method for LES/DES Inflow### Summary
Velocity boundary condition generating synthetic turbulence-alike
time-series for LES and DES turbulent flow computations.
To this end, two synthetic turbulence generators can be chosen:
...### Summary
Velocity boundary condition generating synthetic turbulence-alike
time-series for LES and DES turbulent flow computations.
To this end, two synthetic turbulence generators can be chosen:
- Digital-filter method-based generator (DFM)
\verbatim
Klein, M., Sadiki, A., and Janicka, J.
A digital filter based generation of inflow data for spatially
developing direct numerical or large eddy simulations,
Journal of Computational Physics (2003) 186(2):652-665.
doi:10.1016/S0021-9991(03)00090-1
\endverbatim
- Forward-stepwise method-based generator (FSM)
\verbatim
Xie, Z.-T., and Castro, I.
Efficient generation of inflow conditions for large eddy simulation of
street-scale flows, Flow, Turbulence and Combustion (2008) 81(3):449-470
doi:10.1007/s10494-008-9151-5
\endverbatim
In DFM or FSM, a random number set (mostly white noise), and a group
of target statistics (mostly mean flow, Reynolds stress tensor profiles and
length-scale sets) are fused into a new number set (stochastic time-series,
yet consisting of the statistics) by a chain of mathematical operations
whose characteristics are designated by the target statistics, so that the
realised statistics of the new sets could match the target.
Random number sets ---->-|
|
DFM or FSM ---> New stochastic time-series consisting
| turbulence statistics
Turbulence statistics ->-|
The main difference between DFM and FSM is that the latter replaces the
streamwise convolution summation in DFM by a simpler and a quantitatively
justified equivalent procedure in order to reduce computational costs.
Accordingly, the latter potentially brings resource advantages for
computations involving relatively large length-scale sets and small
time-steps.
### Resolved bugs (If applicable)
Verified for `serial`, `scotch-parallel (4)`, `hierar.-parallel (1 2 2)`, `hierar.-parallel (1 2 4)`, `serial-restart`, and `parallel-restart` in terms of input Reynolds stress tensor components through `channel395DFSEM` tutorial (one-cell domain).
Checked for various possible (commonly encountered) wrong inputs, e.g. arbitrary Reynolds stress tensor components.
### Details of new models (If applicable)
**The model input**:
1. Spatial-variant Reynolds stress symmetric tensor (6-components)
2. Spatial-variant mean velocity profile
3. Spatial-invariant (for now) integral-length scale tensor (9-components)
**The model output**: Stochastic time-series involving the statistics of the model input sets.
**The model computation has four subsequent steps:**
1. Generation of random-number sets obeying the standard normal probability distribution function
2. Analytical computation of digital-filter coefficients as a function of integral-length scales in either Gaussian or exponential form
3. Convolution summation between random-number sets and digital-filter coefficients
4. Embedment of Reynolds stress tensor and mean velocity input into the digital-filtered random-number sets via elementwise multiplication and summation
**Fidelity**:
Preliminary statistically-stationary results from a channel-height profile on the patch (one-cell domain `channel395DFSEM` case: `hierar.-parallel (1 2 4)`):
![stress](/uploads/8dce71846496e6bbc87aca3c78c52bcb/stress.png)
Preliminary **not-statistically developed** (0.6 sec run, ongoing) with **non-optimal input** results from full `channel395DFSEM` case:
![DG-1](/uploads/49f04599abdd34ec9adec65166c8908f/DG-1.png)
**Performance**:
Preliminary comparisons with DFSEM suggests that the current model is ~1.8x faster for the `channel395DFSEM` tutorial.
### Risks
1. Model is itself not divergence-free (yet convertible); therefore, should not be preferred for aeroacoustic applications as is. Nonetheless, the mass flow rate correction reduces the inlet pressure fluctuations to the level of Poletto et al.'s DFSEM (quantified and verified by Bercin in comparison to Moser et al'. DNS data for pressure fluctuations and correlations).
2. For now, Taylor's frozen turbulence hypothesis is applied in the streamwise direction.
3. For now, `bilinear interpolation` is not fully functional.
4. Code duplications with DFSEM exist for template funcs.
5. For now, integral-length scale set (9-components) is spatial-invariant across patch.
6. Further verification is ongoing through high-order statistics from Moser et al.'s DNS data, e.g. correlations, kinetic energy budget, enstrophy and so on.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/236Feature postpro2019-02-20T19:43:43ZMark OLESENFeature postpro### Summary
Extension of insitu visualization (runTimePostProcessing):
- parallel rendering
- direct use of VTK cutting plane and iso-surface filters
- *live* access to simulation data such as lagrangian clouds and geometry patches...### Summary
Extension of insitu visualization (runTimePostProcessing):
- parallel rendering
- direct use of VTK cutting plane and iso-surface filters
- *live* access to simulation data such as lagrangian clouds and geometry patches
- the ability to use stored surfaces and fields originating from another function object (eg, sampledSurfaces)
Significant cleanup and reimplementation of the surface sampling function object and all the surface writers to allow per-surface format specification. Added support for `.vtp` output of sampled surface with multiple fields in a single file.
Stored surface information can now be used for other field calculations (eg, `surfaceFieldValue`)
Images and description of the new functionality are attached to issue #1206v1906AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/257Introduced changes required to make isoAdvector and interIsoFoam work with...2019-06-13T20:48:01ZJohan RoenbyIntroduced changes required to make isoAdvector and interIsoFoam work with...Introduced changes required to make isoAdvector and interIsoFoam work with morphing meshes: 1) In the alphaEqn.H U is made relative to mesh motion before the interface advection step, 2) in isoAdvection::advect() alpha must be multiplied...Introduced changes required to make isoAdvector and interIsoFoam work with morphing meshes: 1) In the alphaEqn.H U is made relative to mesh motion before the interface advection step, 2) in isoAdvection::advect() alpha must be multiplied by Vsc0()/Vsc(). Implementation tested and verified with 1) a spherical interface in a cubic domain with no flow, where the domain walls are squeezed together and 2) a spherical interfacee inside the sloshingCylinder, again with no flow, so the sphere should stay spherical, which it does.v1906Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/269Integration adjoint2019-06-19T21:07:00ZAdminIntegration adjoint## New adjoint optimisation and tools
A set of libraries and executables creating a workflow for performing
gradient-based optimisation loops. The main executable (adjointOptimisationFoam)
solves the flow (primal) equations, followe...## New adjoint optimisation and tools
A set of libraries and executables creating a workflow for performing
gradient-based optimisation loops. The main executable (adjointOptimisationFoam)
solves the flow (primal) equations, followed by the adjoint equations and,
eventually, the computation of sensitivity derivatives.
Current functionality supports the solution of the adjoint equations for
incompressible turbulent flows, including the adjoint to the Spalart-Allmaras
turbulence model and the adjoint to the nutUSpaldingWallFunction, [1], [2].
Sensitivity derivatives are computed with respect to the normal displacement of
boundary wall nodes/faces (the so-called sensitivity maps) following the
Enhanced Surface Integrals (E-SI) formulation, [3].
The software was developed by PCOpt/NTUA and FOSS GP, with contributions from
- Dr. Evangelos Papoutsis-Kiachagias,
- Konstantinos Gkaragounis,
- Professor Kyriakos Giannakoglou,
- Andy Heather
and contributions in earlier version from
- Dr. Ioannis Kavvadias,
- Dr. Alexandros Zymaris,
- Dr. Dimitrios Papadimitriou
[1] A.S. Zymaris, D.I. Papadimitriou, K.C. Giannakoglou, and C. Othmer.
Continuous adjoint approach to the Spalart-Allmaras turbulence model for
incompressible flows. Computers & Fluids, 38(8):1528–1538, 2009.
[2] E.M. Papoutsis-Kiachagias and K.C. Giannakoglou. Continuous adjoint methods
for turbulent flows, applied to shape and topology optimization: Industrial
applications. 23(2):255–299, 2016.
[3] I.S. Kavvadias, E.M. Papoutsis-Kiachagias, and K.C. Giannakoglou. On the
proper treatment of grid sensitivities in continuous adjoint methods for shape
optimization. Journal of Computational Physics, 301:1–18, 2015.
## Integration
Integration into the official OpenFOAM release by OpenCFDv1906AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/271lumped point motion using local linear basic functions (#1341)2020-06-17T14:15:52ZMark OLESENlumped point motion using local linear basic functions (#1341)Extends lumped point motion to support multiple connectivity.
Examples include structures such as bridges.Extends lumped point motion to support multiple connectivity.
Examples include structures such as bridges.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/272Feature mixed precision2019-08-13T11:07:08ZMark OLESENFeature mixed precisionThis set of changes makes it easier to identify and manage binary reading from different representations. For example, a binary file written from an OpenFOAM installation with WM_SP, WM_LABEL_SIZE=32 can be read back as WM_DP and/or WM_L...This set of changes makes it easier to identify and manage binary reading from different representations. For example, a binary file written from an OpenFOAM installation with WM_SP, WM_LABEL_SIZE=32 can be read back as WM_DP and/or WM_LABEL_SIZE=64. This is managed internally by using the "arch" information that is included in the binary output files. For example,
```
FoamFile
{
version 2.0;
format binary;
class vectorField;
arch "LSB;label=32;scalar=64";
location "constant/polyMesh";
object points;
}
```
On reading, the size information is used to determine if the label/scalar sizes in the file correspond to the *native* version of the currently active OpenFOAM installation. If the values are identical, the binary file reading is as always. If, however, there is a discrepancy between the label/scalar sizes in the file and the current OpenFOAM sizes, the values will be read in the raw format and converted on-the-fly. This adds no additional memory overhead, but can potentially result in somewhat lower reading speeds. There are some additional operations when narrowing the representation (eg, reading in double but saving as float) to avoid underflow and overflow, but it cannot work magic. If your input file has 1e10 faces, the addressing will not fit into a signed or unsigned 32-bit integer.
To manage the reading, the new trait structures `is_contiguous`, `is_contiguous_label`, `is_contiguous_scalar` are used. For data payloads that comprise homogenous base types (ie, the lowest level component is entirely scalar or label) the Detail::readContiguous is used for managing the reading in a uniform manner. For heterogeneous data types, the author of the class must address this individually. This is typically in the following form:
```
if (is.format() == IOstream::ASCII)
{
is >> start_ >> end_ >> level_ >> i_ >> j_ >> k_;
}
else if (!is.checkLabelSize<>() || !is.checkScalarSize<>())
{
// Non-native label or scalar size
is.beginRawRead();
readRawScalar(is, start_.data(), vector::nComponents);
readRawScalar(is, end_.data(), vector::nComponents);
readRawLabel(is, &level_);
readRawLabel(is, &i_);
readRawLabel(is, &j_);
readRawLabel(is, &k_);
is.endRawRead();
}
else
{
is.read
(
reinterpret_cast<char*>(&start_),
sizeofFields_
);
}
```
### Limitation
Changes in the endian type are not handled.v1912AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/284Issue 1454 post process2019-10-17T12:26:30ZAdminIssue 1454 post processUpdated `postProcess` for mesh changes to update the function objects instead of performing a full clear-outUpdated `postProcess` for mesh changes to update the function objects instead of performing a full clear-outv1912AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/300Feature expressions2019-12-10T12:10:28ZMark OLESENFeature expressions### Summary
This branch represents an implementation of what is considered to be the most useful aspects of swak4Foam ([Swiss-Army-Knife for FOAM](https://openfoamwiki.net/index.php/Contrib/swak4Foam)) from Bernhard Gschaider, namely ...### Summary
This branch represents an implementation of what is considered to be the most useful aspects of swak4Foam ([Swiss-Army-Knife for FOAM](https://openfoamwiki.net/index.php/Contrib/swak4Foam)) from Bernhard Gschaider, namely the ability to use text-based expressions instead of coding in C++ for the following cases:
- expression-based boundary conditions (also known as _groovy_ boundary conditions)
- expression-based setFields (also known as _funky_ set fields)
The idea of what we currently term *expressions* was pioneered by
(Bernhard Gschaider) and is now firmly established in `swak4Foam`.
Among other things, expressions attempt to bridge the gap between
using standard, predefined boundary conditions and writing dedicated,
special-purpose ones. Although part of this gap is now covered within
OpenFOAM by using dynamically compiled user coding (eg, coded boundary
conditions), there remains substantial areas where it can be
significantly more convenient to have a series of predefined functions
and expression sytax with some access to base OpenFOAM field
functionality that enables rapid deployment of boundary conditions, or
custom-defined `setFields` without writing code.
A significant portion of `swak4Foam` expressions has been adapted for
direct integration into OpenFOAM. During the integration and rewrite,
we have tried to pare things down to a smaller subset with the aim of
covering 90% or more of the common cases. The remaining cases are left
to be reassessed for extending the *expressions* functionality in the
future, but they also may be better served with other approaches (eg,
with coded conditions) that were not available when `swak4Foam` was
originally conceived.
To the greatest extent possible, the integrated *expressions* have
been designed to avoid name clashes with `swak` so it should remain
possible to use the most recent versions of `swak` without problem.
### Risks
- New functionality, so low chance of regression.
- The scope of the functionality will be revised in the future
### Naming (for `swak4Foam` users)
The following are the *expressions* correspondences to `swak`:
- The `exprFixedValue` and `exprGradient` boundary conditions are
roughly equivalent to the _groovy_ boundary conditions.
- The utilities `setExprFields` and `setExprBoundaryFields` are
roughly equivalent to the _funky_ utilities of similar name.
The naming of the boundary conditions and utilities not only reflects
the slightly different input requirements, but simultaneously seeks to
avoid any potential name-clash with `swak4Foam` in a mixed
environment.
The names for the boundary condition dictionary entries tend be
shorter and slightly different (eg, `valueExpr` vs `valueExpression`)
to serve as a small reminder that the *expressions* syntax is slightly
different than the *groovy* equivalents. It also allows the user to
fashion dictionary entries that are sufficient for **both** boundary
condition variants and quickly toggle between them simply by changing
the boundary condition `type`.v1912Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/301Feature particle patch postpro filtering2019-12-10T15:53:15ZAndrew HeatherFeature particle patch postpro filtering### Summary
Adds options to write particle-patch interactions to file, and to select particle fields to post-process for the `patchPostProcessing` cloud function object
### Resolved bugs (If applicable)
none
### Details of new mode...### Summary
Adds options to write particle-patch interactions to file, and to select particle fields to post-process for the `patchPostProcessing` cloud function object
### Resolved bugs (If applicable)
none
### Details of new models (If applicable)
Cloud patch interaction models:
Optionally write patch interaction statistics, e.g. number and mass of particles that stick, escape etc. to file using the optional `writeToFile` entry, e.g.
```
localInteractionCoeffs
{
patches
(
"(walls|cyc.*)"
{
type rebound;
}
"inlet|outlet"
{
type escape;
}
);
// New optional entry
writeToFile yes;
}
```
Cloud function objects:
New `fields` optional entry can be used to select which particle fields to post-process; if empty or the entry is not given all fields are written (to provide backwards compatibility)
```
patchPostProcessing1
{
type patchPostProcessing;
// Optional new entry
fields (position "U.*" d T nParticle);
maxStoredParcels 20;
patches
(
cycLeft_half0
cycLeft_half1
);
}
```
See the `$FOAM_TUTORIALS/lagrangian/reactingParcelFilm/filter` tutorial for an example
### Risks
Low riskv1912Mark OLESENMark OLESENhttps://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/303ENH: Added new function object to compute the Proudman acoustic power2019-12-13T20:04:27ZAndrew HeatherENH: Added new function object to compute the Proudman acoustic power@Roger @Prashant - can you confirm this OK to go in? and any test case/updated tutorial that can be provided?
---
# Details of the new function object:
Calculates the acoustic power due to the volume of isotropic turbulence
usi...@Roger @Prashant - can you confirm this OK to go in? and any test case/updated tutorial that can be provided?
---
# Details of the new function object:
Calculates the acoustic power due to the volume of isotropic turbulence
using Proudman's formula
The acoustic power P_A [W/m3] in terms of turbulence k and \epsilon is given as:
P_A = alpha_\epsilon \rho \epsilon M_t^5
where alpha_\epsilon is a constant (0.1) and
M_t = \frac{\sqrt{2 k}}{a_0}
with a_0 the speed of sound. The acoustic power is also output in
dB using:
L_P = 10 \log \frac{P_A}{P_ref}
where P_ref is a constant (1e-12 W/m3)
Usage
Example of function object specification to calculate the Proudman acoustic
power
proudmanAcousticPower1
{
type proudmanAcousticPower;
libs ("libfieldFunctionObjects.so");
...
// Required additional entries for incompressible calculations
rhoInf 1.225;
aRef 340;
}
Where the entries comprise:
Property | Description | Required | Default value
type | type name: proudmanAcousticPower | yes |
rhoInf | Freestream density for incompressible cases | no |
aRef | Reference spped of sound for incompressible cases | no |
alphaEps | Model coefficient | no | 0.1
Note
- The freestream density and reference speed of sound are only necessary
when a thermodynamics package is unavailable, typically for incompressible
cases.v1912Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/304ENH: Added new limitFields function object2019-12-13T20:04:07ZAndrew HeatherENH: Added new limitFields function object@roger @prashant - can you confirm this OK to go in? and any test case/updated tutorial that can be provided?
---
# Details of the new function object:
Limits fields to user-specified min and max bounds
Usage
Example of func...@roger @prashant - can you confirm this OK to go in? and any test case/updated tutorial that can be provided?
---
# Details of the new function object:
Limits fields to user-specified min and max bounds
Usage
Example of function object specification:
limitFields1
{
type limitFields;
libs ("libfieldFunctionObjects.so");
...
fields (U);
limit max;
max 100;
}
Where the entries comprise:
Property | Description | Required | Default value
type | type name: limitFields | yes |
fields | list of fields to process | yes |
limit | bound to limit - see below | yes |
The limit entry can take the value:
- min : specify a minimum value
- max : specify a maximum value
- both : specify a minimum value and a maximum valuev1912Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/305ENH|BUG: Misc2019-12-12T11:30:37ZKutalmış BerçinENH|BUG: MiscAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/316New VOF multiphaseStabilizedTurbulence fvOption2019-12-19T08:46:51ZAndrew HeatherNew VOF multiphaseStabilizedTurbulence fvOption### Summary
Applies corrections to turbulence kinetic energy equation and turbulence viscosity field for incompressible multiphase flow cases.
Turbulence kinetic energy is over-predicted in incompressible VOF solvers at the phase i...### Summary
Applies corrections to turbulence kinetic energy equation and turbulence viscosity field for incompressible multiphase flow cases.
Turbulence kinetic energy is over-predicted in incompressible VOF solvers at the phase interface and throughout the water column in nearly-potential flow regions beneath surface waves.
This fvOption applies corrections based on the references:
Buoyancy source term in turbulence kinetic energy equation:
Devolder, B., Rauwoens, P., and Troch, P. (2017).
Application of a buoyancy-modified k-w SST turbulence model to
simulate wave run-up around a monopile subjected to regular waves
using OpenFOAM.
Coastal Engineering, 125, 81-94.
Correction to turbulence viscosity:
Larsen, B.E. and Fuhrman, D.R. (2018).
On the over-production of turbulence beneath surface waves in
Reynolds-averaged Navier-Stokes models
J. Fluid Mech, 853, 419-460
### Resolved bugs (If applicable)
See #1433
### Details of new models (If applicable)
The implementation is based on the form for the k-epsilon turbulence model.
Example usage:
multiphaseStabilizedTurbulence1
{
type multiphaseStabilizedTurbulence;
active yes;
multiphaseStabilizedTurbulenceCoeffs
{
// Optional coefficients
lambda2 0.1; // A value of 0 sets the nut correction to 0
Cmu 0.09; // from k-epsilon model
C 1.51; // model coefficient from k-omega model
alpha 1.36; // 1/Prt
}
}
The model `C` coefficient for the k-epsilon model equates to C2/C1 = 1.33; the (default) value of 1.51 comes from the k-omega model and is more conservative.
### Risks
Modular - low risk
### Credits
Thanks go to the Turbulence Technical Committee, and the useful discussions with and code testing by Bjarke Eltard-Larsen and David Fuhrman (Technical University of Denmark).v1912https://develop.openfoam.com/Development/openfoam/-/merge_requests/331Submodule visualization2020-01-23T14:24:33ZMark OLESENSubmodule visualizationThis finalises the work done to collect visualization-related items:
- catalyst
- paraview-plugins
- runTimePostProcessing
into a single place.
- Makes it easier to make related code changes.
- Makes it easier to mix and match differen...This finalises the work done to collect visualization-related items:
- catalyst
- paraview-plugins
- runTimePostProcessing
into a single place.
- Makes it easier to make related code changes.
- Makes it easier to mix and match different combinations of VTK/ParaView versions and capabilities (Eg, MESA, MPI etc).
Replaces the standalone catalyst submodule.Andrew 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/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/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/364ENH: Miscellaneous enhancement/features and bug fixes2020-06-11T12:30:36ZKutalmış BerçinENH: Miscellaneous enhancement/features and bug fixesv2006Andrew HeatherAndrew Heather