openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2022-06-08T13:23:09Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/547ENH: DMD: add multi-patch input functionality2022-06-08T13:23:09ZKutalmış BerçinENH: DMD: add multi-patch input functionalityEP#1796, EP#1873
### Summary
This feature allows users to specify multiple patches in DMD calculations:
```
DMD1
{
// Optional entries
// Option-1
patch <word>;
// Option-2
patches ...EP#1796, EP#1873
### Summary
This feature allows users to specify multiple patches in DMD calculations:
```
DMD1
{
// Optional entries
// Option-1
patch <word>;
// Option-2
patches (<wordRes>);
}
```
The DMD snapshots concatenate each patch field, e.g. for velocity field:
`(u1 v1 w1 u2 v2 w2 u1_o v1_o w1_o u2_o v2_o w2_o)`
where "1" and "2" indicate different patches, "u v w" different components of a vector, and "o" the previous DMD step.
Also, the most expensive parts of the `STDMD` implementation were identified and reworked resulting in various reductions in calculation runtime.
For example, the timing of the standard "cylinder2D" tutorial (i.e. with all `STDMD` function objects are active), the duration of the parallel 12-processor simulation has been reduced from ~200secs to ~80secs during local tests, approximately a ~60% reduction.
Another test of DrivAer was reported to provide approximately 10x speedup.
### Tests
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/433ENH: binField: new function object for data binning2022-06-09T09:33:22ZKutalmış BerçinENH: binField: new function object for data binning#### Summary
##### Function object: forces/forceCoeffs
- Refactors the `forces` and `forceCoeffs` function objects.
- Removes the binning - it is now handled by the new `binField` function object.
- Enables runtime selection of operand...#### Summary
##### Function object: forces/forceCoeffs
- Refactors the `forces` and `forceCoeffs` function objects.
- Removes the binning - it is now handled by the new `binField` function object.
- Enables runtime selection of operand coefficients by the `coefficients` entry.
- `force`/`moment`/`forceCoeff`/`momentCoeff` fields per FO are always registered to the database.
- The data components were renamed from 'normal,tangential,porous' to 'pressure,viscous,internal'
- Redundant parentheses were removed from the data files in order to ease data manipulation.
##### Function object: binField
- The new 'binField' function object calculates binned data,
where specified patches are divided into segments according to
various input bin characteristics, so that spatially-localised
information can be output for each segment.
- Two `binModel` is available:
- `singleDirectionUniformBin`: calculates binned data in a specified direction.
- `uniformBin`: calculates binned data in multiple segments according to
a specified Cartesian or cylindrical coordinate system.
- Unlike the `forces/forceCoeffs`'s binning, the `binField` outputs `normal` and `tangential` components of specified patch data rather than `pressure` and `viscous` components.
- Output variables:
- `total`: the sum of `patch` and `internal`
- `patch`: patch data
- `internal`: porous data from specified cell zones
- `normal` and `tangential`: orthogonal components of the `patch` data
#### Tests
- [x] `linux64ClangDPInt32Opt`
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] Alltestv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/549support surface writer output transform (#2505)2022-06-13T11:37:19ZMark OLESENsupport surface writer output transform (#2505)- this allows the "relocation" of sampled surfaces. For example,
to reposition into a different coordinate system for importing
into CAD.
- incorporate output scaling for all surface writer types.
This was previously done on an a...- this allows the "relocation" of sampled surfaces. For example,
to reposition into a different coordinate system for importing
into CAD.
- incorporate output scaling for all surface writer types.
This was previously done on an adhoc basis for different writers,
but with now included in the base-level so that all writers
can automatically use scale + transform.
Example:
```
formatOptions
{
vtk
{
scale 1000; // m -> mm
transform
{
origin (0.05 0 0);
rotation axisAngle;
axis (0 0 1);
angle -45;
}
}
}
```
An example of transform in action. Used to reposition the output slices:
![transform-surfaceWrite](/uploads/69bf67dbc06c8622a008d84eed4dd8cc/transform-surfaceWrite.png)v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/548species and heat adsorption BC's and fvOption source2022-06-14T11:28:42ZSergio Ferrarisspecies and heat adsorption BC's and fvOption sourceImplementation of species and heat adsorption BC's.
Implementation of a fvOption source on cells attached to patchesImplementation of species and heat adsorption BC's.
Implementation of a fvOption source on cells attached to patchesv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/545ENH: setTurbulenceFields: new automatic initialisation method for turbulence ...2022-06-14T13:22:18ZKutalmış BerçinENH: setTurbulenceFields: new automatic initialisation method for turbulence fields#### Acknowledgement
OpenCFD would like to acknowledge and thank **Prof. Rémi Manceau** for providing the governing equations for `setTurbulenceFields`, elaborate suggestions and critical recommendations. Highly appreciated.
#### Aim...#### Acknowledgement
OpenCFD would like to acknowledge and thank **Prof. Rémi Manceau** for providing the governing equations for `setTurbulenceFields`, elaborate suggestions and critical recommendations. Highly appreciated.
#### Aim
Implement and evaluate the two-step automatic initialization procedure for RANS computations introduced by Manceau (n.d.).
#### Methodology
- Plane channel flow at ReTau=180, 395, 590 (Moser et al., 1991) and =4179 (Lozano-Duran & Jimenez, 2014)
- NASA Turbulence Modelling Resource on various physics:
- 2DCC: 2D Convex curvature boundary layer
- 2DML: 2D Mixing layer
- 2DB: 2D Bump-in-channel
- 2DZP: 2D Zero pressure gradient flat plate
- 2DANW: 2D Airfoil near-wake
#### Results
**2DML: 2D Mixing layer**
<img src="/uploads/e00398017af9f013108c7ecb5dd288cb/Screenshot_from_2022-05-31_11-25-20.png" width="75%" height="75%">
<img src="/uploads/f1866890400631b1306f31713c981074/Screenshot_from_2022-05-31_11-25-30.png" width="75%" height="75%">
**Plane channel flow, ReTau=4179**
<img src="/uploads/f085f52634d45a085bd90d05da3be854/Screenshot_from_2022-05-31_11-31-54.png" width="75%" height="75%">
### Meta-data
EP#1805
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error
### Discussion
- The initialisation method may help to improve convergence in the first `O(10)` time steps, and fidelity of results.
- The initialisation method does not take input turbulence intensity and/or input viscosity ratios (mut/mu) into account.v2206Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/518ENH: adjoint code review2022-06-15T09:36:08ZVaggelis PapoutsisENH: adjoint code review### Summary
An enhancement and review of the adjoint optimisation library, featuring
- the adjoint to the k-ω SST turbulence model
- easier and more accurate restarted runs
- reduced turnaround times
- reduced peak memory consumpti...### Summary
An enhancement and review of the adjoint optimisation library, featuring
- the adjoint to the k-ω SST turbulence model
- easier and more accurate restarted runs
- reduced turnaround times
- reduced peak memory consumption
### Resolved bugs
Partially resolves #2502, allowing the update of the nearWallDist field throughout an optimisation loop.
### Details of the code enhancement
Added the adjoint to the k-ω SST turbulence model for incompressible flows. This allows for avoiding the "frozen turbulence" assumption when using this turbulence model within an optimisation loop or when computing sensitivity maps. Making the "frozen turbulence" assumption, i.e. assuming that the turbulent viscosity field does not change when the shape changes throughout the optimisation, can lead to erroneously computed sensitivity derivatives. As an example, the drag sensitivity maps computed on the surface of the Ahmed body using the "frozen turbulence" assumption and the fully differentiated k-ω SST model are depicted below
![Ahmed_kOmega_back](/uploads/a6edbbd484421ef4cd8dfc6a147bbfb2/Ahmed_kOmega_back.png)
featuring areas where the sign of the sensitivity map changes when turbulence is not differentiated.
Taking this a step further and executing optimisations using "frozen turbulence" (FT) and "differentiated turbulence" (DT) highlights the need for differentiating the k-ω SST model in this case
![ahmed_kOmega_opt](/uploads/d742bb48fc2d9e34cf888ceb5f01afac/ahmed_kOmega_opt.png)
The DT approach reduces drag by more the 6% within 20 optimisation cycles whereas the optimisation based on the FT assumption diverges after the fourth cycle.
The work is based on [1] with changes in the discretisation of a number of differential operators and the formulation of the adjoint to the wall functions employed by the primal model.
**Source code**
$FOAM_SRC/optimisation/adjointOptimisation/adjoint/turbulenceModels/incompressibleAdjoint/adjointRAS/adjointkOmegaSST
**Examples**
$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/naca0012/kOmegaSST/lift
$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/sbend/turbulent/kOmegaSST/opt
**References**
[1] Kavvadias, I., Papoutsis-Kiachagias, E., Dimitrakopoulos, G., & Giannakoglou, K. (2014). The continuous adjoint approach to the k–$omega$ SST turbulence model with applications in shape optimization. Engineering Optimization, 47(11), 1523-1542. https://doi.org/10.1080/0305215X.2014.979816
**Attribution**
The initial implementation, as described in [1], was performed by Dr. Ioannis Kavvadias.
### Details of the code review
Three main aspects are addressed
- Continuation
Restarting a (partially) already ran optimisation is now easier and more accurate.
1. Adjoint solvers write/read their sensitivity derivatives under the 'uniform'
folder, to avoid potential loss of accuracy due to I/O.
2. Volumetric B-Splines control points of each optimisation cycle are written
under 'uniform' and support also binary I/O. As a consequence, the
controlPointsDefinition in constant/dynamicMeshDict does not need to be
changed to 'fromFile' anymore in order to perform the continuation, removing
a potential source of miss-setups.
3. The adjoint grid displacement field (ma) is now appended by the name of the
adjoint solver, if more than one exist. This facilitates continuation since,
before the change, only the ma field of the last adjoint solver was written
to file. No changes to fvSchemes/fvSolution are necessary though.
- Reduced turnaround times
A number of changes to reduce the solution turnaround time of the adjoint
equations (see bac1d8bae41c for details). In brief, these include caching of
some expensive but constant quantities and removing some coding shortcomings.
All cases should see some benefit (e.g. around 9.5% reduction in the turnaround
time of the adjoint solver for the motorbike tutorial) but the latter can be
even more pronounced in cases with many outlet boundaries.
- Reduced peak memory consumption
The peak memory consumption of the adjoint code is observed during the
computation of sensitivity derivatives, when using either the FI or the E-SI
approach, due to the need of manipulating a number of volTensorFields necessary
to compute the multiplier of the spatial gradient of the grid sensitivities.
This part of the code has been re-written to reduce this peak memory consumption.
### Risks
No changes to the user input, apart from the second item in the 'Continuation'
listing above, which should make the setup of continuation runs easier/more straightforward.
Additionally, sensitivities are now computed at the end of each adjoint solver,
instead of being computed when all adjoint solvers are finished, but this
should not affect the code behaviour and/or setup in any way.
Finally, even though 5937c37a resolves the main issue in #2502, it practically disables caching of gradients after the
first mesh update within an optimisation loop (see #2502 for a discussion).v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/550s2s linear system solution using lduMatrix2022-06-15T12:26:28ZSergio Ferrariss2s linear system solution using lduMatrix s2s linear system solution using lduMatrix for qr s2s linear system solution using lduMatrix for qrv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/542General enhancement to icoReactingMultiphaseInterFoam solver, sub-models and ...2022-06-22T09:18:53ZSergio FerrarisGeneral enhancement to icoReactingMultiphaseInterFoam solver, sub-models and FO's1) Name changing and namespace used for some multi phase class used in icoReactingMultiphaseInterFoam.
2) Creating a new derivedFvPatch for thermal BC's (detached from TurbulenceCompressible) which allows to
use phase system models i...1) Name changing and namespace used for some multi phase class used in icoReactingMultiphaseInterFoam.
2) Creating a new derivedFvPatch for thermal BC's (detached from TurbulenceCompressible) which allows to
use phase system models in FO's. This new lib was added to all the thermal solvers
3) Adding new diffusion-based mass transfer model to icoReactingMultiphaseInterFoam
4) Improving consistency of Hf between phases (updated tutorials entries)
5) HeatFlux and htc FO's are available to use with icoReactingMultiphaseInterFoam
NOTE: There is memory leak problem at the end of the run when using icoReactingMultiphaseInterFoam and 'fieldFunctionObjects' is loaded usng lddOpen. NEED TO BE REVIEWEDv2206Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/552ENH: multiFieldValue: add divide and cmptDivide operations2022-07-01T12:55:33ZKutalmış BerçinENH: multiFieldValue: add divide and cmptDivide operationsAdds two new options into `multiFieldValue` FO:
divide | Divide first entry by values
cmptDivide | Divide first entry by componentwise values
EP1898Adds two new options into `multiFieldValue` FO:
divide | Divide first entry by values
cmptDivide | Divide first entry by componentwise values
EP1898Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/554BUG: setTurbulenceFields: update processor boundaries (fixes #2527)2022-07-04T15:26:56ZKutalmış BerçinBUG: setTurbulenceFields: update processor boundaries (fixes #2527)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/553ENH: oscillatingLinearMotion: add optional phase- and vertical-shift entries2022-07-04T15:27:59ZKutalmış BerçinENH: oscillatingLinearMotion: add optional phase- and vertical-shift entriesThe governing equation of `oscillatingLinearMotion` for the displacement was changed to with `Function1` input entries:
```math
y = A\, sin(B (t + C)) + D
```
where:
```
y | Displacement [m] (vector)
A | Ampl...The governing equation of `oscillatingLinearMotion` for the displacement was changed to with `Function1` input entries:
```math
y = A\, sin(B (t + C)) + D
```
where:
```
y | Displacement [m] (vector)
A | Amplitude [m] (vector)
B | Radial velocity [rad/s] (scalar)
C | Phase-shift to left [s] (scalar)
D | Vertical shift [m] (vector)
```
EP1925Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/528Pstream performance and handling improvements2022-07-08T10:40:49ZMark OLESENPstream performance and handling improvements- MPI intrinsics for common primitive types (#2351)
- new broadcast Pstream for one-to-all communications (RIST #2371)
- wrap MPI broadcast for OpenFOAM _scatter_ operations
- improved globalIndex handling
- isoAdvection communication im...- MPI intrinsics for common primitive types (#2351)
- new broadcast Pstream for one-to-all communications (RIST #2371)
- wrap MPI broadcast for OpenFOAM _scatter_ operations
- improved globalIndex handling
- isoAdvection communication improvementsv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/551Update of view factor generation using 2AI and 2LI methods plus CGAL for ray ...2022-08-12T08:53:39ZSergio FerrarisUpdate of view factor generation using 2AI and 2LI methods plus CGAL for ray tracing### Summary
This view factors generation application uses a combined approach of
double area integral (2AI) and double linear integral (2LI). 2AI is used
when the two surfaces are 'far' apart and 2LI when they are 'close'.
...### Summary
This view factors generation application uses a combined approach of
double area integral (2AI) and double linear integral (2LI). 2AI is used
when the two surfaces are 'far' apart and 2LI when they are 'close'.
The distance between faces is calculating a ratio between averaged areas and the distance between face
centres. 2LI is integrated along edges using Gaussian quadrature with a given tolerance.
This approach doesn't use face agglomeration as pre-processing step.
Optional new feature can be used to solve the system of equations from the s2s system using the
standard iterative linear solvers in OpenFOAM.
### Resolved bugs
The old method used 2AI and agglomeration for all the view fators. The 2AI is not accurate for faces which
are in close proximity. The agglomeration process proved to be problematic concerning the face centre and normal calculation.
### Details of new models
The extra inputs in the s2s dictionary are:
GaussQuadTol 0.1; // GaussQuad integral error tolerance (default : 0.01). Used to decide when to increase order of integration.
distTol 8; // relative distance (default : 8). For <distTol : use 2LI, >distTol : use 2AI
alpha 0.22; // Constant model use for common edges for 2LI (default : 0.22). Approx for integral value of duplicate edges.
intTol 1e-2; // (m) Interval tolerance. This is used for ray shooting from
// face centre to face centre plus `intTol` in order to avoid the ray to hit the same face where it was originated. (default : 1e-2)
The default values are generally reasonable for a wide range of cases.
The optional iterative linear solver is specified in the radiationProperty dictionary:
```
viewFactorCoeffs
{
smoothing false; // Use for closed surfaces where sum(Fij) = 1
constantEmissivity true;
nBands 1;
useDirectSolver false; // Use direct solver on master or fully parallel iterative solver
}
```
NOTE: In this development face agglomeration is not needed. The model will create an identity list if it is not present. Thus, it is not necessary for the user to run `faceAgglomerate`. But, the framework for using faceagglomeration was left inside the model as it can be needed in later stages.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/558snappyHexMesh : refine based on curvature2022-08-18T12:27:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh : refine based on curvature### Summary
Currently snappyHexMesh refines based on geometry intersection by the rays between neighbouring cells. It looks at the angle between the local normal at these intersection points and decides if the geometry forms a feature. ...### Summary
Currently snappyHexMesh refines based on geometry intersection by the rays between neighbouring cells. It looks at the angle between the local normal at these intersection points and decides if the geometry forms a feature. This is determined by the `resolveFeatureAngle` parameter.
In this project the curvature based refinement has been extended to look at the actual (triangulated) surface to decide if the surface requires refinement to resolve.
The algorithm in `snappyHexMesh` pre-calculates the needed refinement level for each triangle on the surface and this then triggers refinement when actually doing the castellation. The behaviour is controlled by the `resolveFeatureAngle` parameter and the new optional `curvatureLevel` parameter:
```
// Additional refinement for regions of high curvature. Expressed
// (bit similar to gapLevel) as:
// - number of cells per radius of curvature. (usually a few is
// good enough)
// - starting cell level? Not used at the moment.
// - maximum cell level. This can be smaller or larger than the
// max 'surface' level
// - minumum curvature radius to ignore (expressed as a cell level).
// This can be used to avoid detecting small sharp surface
// features. Set to -1 to ignore.
//
curvatureLevel (10 0 10 -1);
```
See https://exchange.openfoam.com/node/991, https://exchange.openfoam.com/node/1823
The logic is:
- calculate the curvature of the surface
- unmark points on edges with angles sharper than `resolveFeatureAngle` (these are resolved by feature-edge snapping)
- convert the curvature + specified number-of-cells-per-radius to a needed refinement level
- clip to the specified maximum refinement level
- store on the surface such that it gets used during follow-on refinement
In some cases the curvature refinement should only be applied to a particular geometric region. One way is to extract part of the surface (using e.g. the `surfaceSubset` application or the `subTriSurfaceMesh` surface). Another way is to use the `limitRegions` functionality inside `snappyHexMesh`:
```
limitRegions
{
box_limit // geometry defining region without explicit refinement
{
// Don't refine at all inside 'box_limit'
mode inside;
levels ((10000 0));
}
}
```
In the tutorial `mesh/snappyHexMesh/block_with_curvature` this has been used to limit the curvature refinement to outside a box.
Without limitRegions: ![no_limitRegions](/uploads/9d15a31a47040e2a5716bac3cb5db3ba/no_limitRegions.png)
With limitRegions: ![limitRegions](/uploads/d60c025c0484f05f2f0ab4d9a29ab03f/limitRegions.png). Note the bleeding of the refinement to inside the limitRegion due to the 2:1 constraint.
### Resolved bugs (If applicable)
(Links to issues)
### Details of new models (If applicable)
See above
### Risks
- this is still an experimental feature - it might not cover all situations
- it only measures curvature on a (single) surface - it does not use the mesh intersections (like e.g. `resolveFeatureAngle` does). This might be a future extension
- if e.g. subTriSurfaceMesh is used to extract part of the geometry this will cause duplicate triangles - each with their own patch. This might lead to inconsistent patching (since it randomly chooses either one or the other patch) and hence snapping.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/557ENH: fvOptions: refactor and extend effectivenessHeatExchangerSource2022-09-07T13:55:04ZKutalmış BerçinENH: fvOptions: refactor and extend effectivenessHeatExchangerSource#### Summary
- rename effectivenessHeatExchangerSource -> heatExchangerSource
- introduce submodels:
- effectivenessTable (previous behaviour)
- referenceTemperature
- the referenceTemperature submodel uses a reference temperature
...#### Summary
- rename effectivenessHeatExchangerSource -> heatExchangerSource
- introduce submodels:
- effectivenessTable (previous behaviour)
- referenceTemperature
- the referenceTemperature submodel uses a reference temperature
which is either a scalar or calculated from a 2D interpolation
table in order to calculate the heat exchange.
- the following figure shows the verification level of
the comparisons between the original and refactored `referenceTemperature`
modules in terms of average temperature.
<img src="/uploads/40d9aad34807cfb724ecc81442327e5b/image.png" width="50%" height="50%">
#### Metadata
- EP1903
- diligently reviewed and tested by @Tobi (thanks Tobi)
- see `v2212/01-heatExchangerSource` for a test caseAndrew 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/562ENH: noiseModels - replaced graph usage by writeFile2022-10-04T13:50:34ZAndrew HeatherENH: noiseModels - replaced graph usage by writeFileHeader information now includes, e.g.
f [Hz] vs P(f) [Pa]
Lower frequency: 2.500000e+01
Upper frequency: 5.000000e+03
Window model: Hanning
Window number: 2
Window samples: 512
Window overlap %: 5.000000e+01
...Header information now includes, e.g.
f [Hz] vs P(f) [Pa]
Lower frequency: 2.500000e+01
Upper frequency: 5.000000e+03
Window model: Hanning
Window number: 2
Window samples: 512
Window overlap %: 5.000000e+01
dBRef : 2.000000e-05
Area average: false
Area sum : 6.475194e-04
Number of faces: 473
Note: output files now have `.dat` extension
Testing: check output from
`$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/vortexShed`v2212Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/565Feature master coarsest multi masters2022-10-20T09:14:25ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comFeature master coarsest multi masters# Processor agglomeration in the GAMG linear solver
The current `GAMG` linear solver supports processor agglomeration on the coarsest level using the `masterCoarsest` processor agglomerator method. This removes communication, increases ...# Processor agglomeration in the GAMG linear solver
The current `GAMG` linear solver supports processor agglomeration on the coarsest level using the `masterCoarsest` processor agglomerator method. This removes communication, increases implicitness but increases the size of the coarsest level and at some core count will not be beneficial.
## Extend `masterCoarsest` for multiple master processors
A test was done varying the number of master processors - in below table it starts at a single master (responsible for 1728 processors) and increases the number of masters to 48 (each responsible for 36 processors).
| Coarsest level procs | run1 (s) | run2 (s) |
|-----------------------:|---------:|---------:|
| 1 (1728) | 193 | 219 |
| 2 (864) | 141 | 156 |
| 4 (432) | 167 | 126 |
| 8 (216) | 135 | 114 |
| 16 (108) | 140 | 126 |
| 48 (36) | 247 | -- |
Especially run2 shows a benefit of using more than one master processor. Other testing on a different cluster has shown no benefit of master-coarsest on one or more than one master processor - it all depends on cost of local computation versus communication/explicitness.
Above testing was done using complicated dictionary scripting to manually agglomerate processors. In this version this has been integrated into the `masterCoarsest` processor agglomeration using the new `nMasters` or `nProcssorsPerMaster` keyword:
```
{
solver GAMG;
..
processorAgglomerator masterCoarsest;
nCellsInCoarsestLevel 1;
nMasters 2;
}
```
With debug switches in the system/controlDict
```
DebugSwitches
{
// Print number of processors per master
masterCoarsest 1;
// Print agglomeration
GAMGAgglomeration 1;
}
```
we can see the effect of using processor agglomeration on a simple case decomposed onto 17 processors:
```
masterCoarsest : agglomerating
master procs
0 9 (1 2 3 4 5 6 7 8)
9 8 (10 11 12 13 14 15 16)
GAMGAgglomeration:
local agglomerator : faceAreaPair
processor agglomerator : masterCoarsest
nCells nFaces/nCells nInterfaces nIntFaces/nCells profile
Level nProcs avg max avg max avg max avg max avg
----- ------ --- --- --- --- --- --- --- --- ---
0 17 719 725 1.922 1.926 3.529 5 0.1093 0.1335 1.797e+04
1 17 359 362 1.966 2.109 3.529 5 0.1864 0.2632 7291
2 17 176 181 2.352 2.769 3.529 5 0.272 0.436 2810
3 17 86 90 2.344 2.593 3.529 5 0.4415 0.7738 930.4
4 17 42 44 2.291 2.442 3.529 5 0.6747 1.22 320.9
5 17 20 22 2.094 2.286 3.529 5 0.967 1.895 98.41
6 17 9 11 1.741 2 3.529 5 1.35 2.444 29
7 17 4 5 1.149 1.6 3.529 5 2.082 3.5 6
8 2 15 18 1.585 1.615 1 1 0.5962 0.6923 40
9 2 8 9 1.417 1.5 1 1 0.7083 0.75 15
```
Tutorials:
- compressible/rhoSimpleFoam/squareBendLiq (use of `masterCoarsest`)
Source code
- src/OpenFOAM/matrices/lduMatrix/solvers/GAMG/GAMGProcAgglomerations/masterCoarsestGAMGProcAgglomeration/masterCoarsestGAMGProcAgglomeration.CMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/560Integration of grey area turbulence models from Upstream CFD2022-11-07T11:33:34ZAndrew HeatherIntegration of grey area turbulence models from Upstream CFD## Summary
- Refactoring of Spalart-Allmaras (SA) models
- New class hierarchy to reduce code duplication
- Trip term (ft2) now on a user switch
- Was previously active, now deactivated by default
- Enhancements to DES models...## Summary
- Refactoring of Spalart-Allmaras (SA) models
- New class hierarchy to reduce code duplication
- Trip term (ft2) now on a user switch
- Was previously active, now deactivated by default
- Enhancements to DES models to include grey area model effects in collaboration with @MarianFuchs, Upstream CFD GmbH
- sigma extension for SA and k-omega DES, DDES models
- New LES delta functions
- `DeltaOmegaTilde`
- `SLADelta`
- New sigma LES model
- Extended `turbulenceFields` function object
- Added writing of DES shielding function (fd) and LES region indicator fields
- Added warnings for DES model usage; DDES forms should be employed instead
## Details of new models (If applicable)
### Grey area turbulence
The new sigma treatment is available for the models:
- `SpalartAllmarasDES`, `SpalartAllmarasDDES`, `SpalartAllmarasIDDES`
- `kOmegaSSTDES`, `kOmegaSSTDDES`, `kOmegaSSTIDDES`
and activated via the `useSigma` switch, e.g.
```
simulationType LES;
LES
{
LESModel SpalartAllmarasDDES;
SpalartAllmarasDDESCoeffs
{
useSigma true; // <-- new entry
}
//delta SLADelta; // DeltaOmegaTilde;
delta DeltaOmegaTilde;
DeltaOmegaTildeCoeffs
{}
...
}
```
Test case: [wallMountedHump.tgz](/uploads/cea302870310f2b2bf17dc81ff1fbcae/wallMountedHump.tgz) provided by @MarianFuchs
References:
- Mockett, C. et al. (2015). Two Non-zonal Approaches to Accelerate RANS to LES Transition of Free Shear Layers in DES. In: Girimaji, S., Haase, W., Peng, SH., Schwamborn, D. (eds) Progress in Hybrid RANS-LES Modelling. Notes on Numerical Fluid Mechanics and Multidisciplinary Design, vol 130. Springer, Cham. https://doi.org/10.1007/978-3-319-15141-0_15
- Fuchs, M. et al. (2016). Further Assessment of the Grey-Area Enhanced σ-DES Approach for Complex Flows. ERCOFTAC Bulletin 108
- Fuchs, M. et al. (2015). Assessment of novel DES approach with enhanced SGS modelling for prediction of separated flow over a delta wing. AIAA 2015-3433. https://doi.org/10.2514/6.2015-3433
### Extended turbulenceFields function object
The `turbulenceFields` function object now included writing for:
- `fd` : DES shielding function
- `LESRegion` : LES indicator field
An example usage has been added to the `$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/vortexShed` case:
```
functions
{
turbulenceFields1
{
type turbulenceFields;
libs (fieldFunctionObjects);
writeControl writeTime;
fields (fd LESRegion);
}
...
```
### Risks
- Possible regressions in SA models following code refactoringv2212Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/567ENH: ensightToFoam: Ensight Gold mesh converter2022-11-07T21:26:38ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: ensightToFoam: Ensight Gold mesh converter# Ensight format mesh reading
This release adds an Ensight Gold mesh importer is supported. It can handle all cell shapes supported by the `foamToEnsight` converter. It currently gets given the geometry file name (geo`extension`). It su...# Ensight format mesh reading
This release adds an Ensight Gold mesh importer is supported. It can handle all cell shapes supported by the `foamToEnsight` converter. It currently gets given the geometry file name (geo`extension`). It supports both ascii and binary formats.
Supported keywords:
- `extents`
- `node id 'given', 'ignore', 'assign'`
- `node_ids`
- `element id 'given', 'ignore', 'assign'`
- `element_ids`
- `part`
- `coordinates`
- `tetra4`
- `pyramid5`
- `penta6`
- `hexa8`
- `nfaced`
- `tria3`
- `quad4`
- `nsided`
It does not support
- 2D (finite-area) meshes
- `block` structured meshes
- quadratic elements (e.g. `twenty node hexahedron`)
- faceZones
- baffles (they probably get merged away unless they are in the first part - not tested)
It reads all parts, combines all the cells (`tetra3`, `hexa8` etc) and determines the outside faces. It merges all the points using a geometric test (see below) and uses all faces (`tria3` etc.) to patch any outside faces. Patch names are the original part names with any illegal word symbol replaced by '_'. Any remaining outside faces get added to a `defaultFaces` patch of type `empty`.
## Options
- `mergeTol` : supply optional merge tolerance to get the correspondence between points of different parts. Default is 1e-10 of the bounding box of all points. Specifying 0 disables any point merging (and hence patching).
- `scale` : specify optional scaling for the coordinates. Default is no scaling. Scaling can e.g. be used if the mesh is specified in [mm] instead of [m].
- `keepHandedness` : by default the mesh reader will flip (non-polyhedral) cells with negative volume. It will display warning messages of the form
```
zero or negative pyramid volume:
```
Use the flag to disable this check and use the normal vertex numbering.
Source code
- application/utilities/mesh/conversion/ensightToFoamMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com