openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2022-10-20T09:14:25Zhttps://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/564ENH: chtMultiRegionFoam - add frozenFlow option2022-12-14T10:59:02ZKutalmış BerçinENH: chtMultiRegionFoam - add frozenFlow optionAdds `frozenFlowOption` into `chtMultiRegion*` solvers.
#### Meta-data
* EP1924
* Test case: [multiRegionHeater.zip](/uploads/a7273dfb758f76e5ef9f99a76f299939/multiRegionHeater.zip)
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux...Adds `frozenFlowOption` into `chtMultiRegion*` solvers.
#### Meta-data
* EP1924
* Test case: [multiRegionHeater.zip](/uploads/a7273dfb758f76e5ef9f99a76f299939/multiRegionHeater.zip)
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error/No change in existing outputv2212Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/563ENH: functionObjects: refactor and extend histogram2022-11-14T17:34:56ZKutalmış BerçinENH: functionObjects: refactor and extend histogram- new submodels:
- 'equalBinWidth': groups data into bins of equal widths (previous behaviour)
- 'unequalBinWidth': groups data into bins of unequal widths
- output files per time-step are replaced with a single output file
- silen...- new submodels:
- 'equalBinWidth': groups data into bins of equal widths (previous behaviour)
- 'unequalBinWidth': groups data into bins of unequal widths
- output files per time-step are replaced with a single output file
- silently deprecates the input entries: 'setFormat' and 'formatOptions'
#### Meta-data
* EP1969
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error/No change in existing outputv2212Andrew 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/561ENH: faceZoneReferenceTemperature: new heatTransferCoeff model2022-11-21T15:59:47ZKutalmış BerçinENH: faceZoneReferenceTemperature: new heatTransferCoeff modelEP1947 - see `faceZoneReferenceTemperature.H` for model usage.EP1947 - see `faceZoneReferenceTemperature.H` for model usage.v2212Andrew HeatherAndrew Heatherhttps://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/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/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/555overset modifications: allow overset pacthes overlap, allow fringe faces walk...2022-11-14T15:49:00ZSergio Ferrarisoverset modifications: allow overset pacthes overlap, allow fringe faces walk, mass conservation update### Summary
This merge addresses three main topics:
1) Allow overset patches displace outside the background domain.
2) Allow fringe faces away from the HOLE cells in the background domain
3) Some option to improve mass conservation in...### Summary
This merge addresses three main topics:
1) Allow overset patches displace outside the background domain.
2) Allow fringe faces away from the HOLE cells in the background domain
3) Some option to improve mass conservation in overset
1) overset patches can displace outside the domain. The problem of selecting the correct donors was addressed creating a new type of cell type named "POROUS". In these cells, DONORS can't be selected as they lay close to the end of the background domain. Any attempt to find a suitable donor proved to be unstable. Therefore these cells are not interpolated but let connected withing its mesh and solved locally. As these cells are normally close to wall without a proper BC applied , if left unweighted they lead to divergency, to avoid this a small damping effect is introduce using fvOption. Tests showed that damping U is robust enough to keep U-p stable.
Tutorials:
/tutorials/multiphase/overInterDyMFoam/twoSquaresOutDomain/
/tutorials/incompressible/overPimpleDyMFoam/rotatingSquare/
The fvOption is as:
limitU
{
type velocityDampingConstraint;
active true;
selectionMode cellType;
UMax 0;
C 1;
}
A constant C of '1' seems to be working generally. Of course , the solution on this cell is not accurate as an artificial porous cell is being introduced, on the other hand, cells next to wall will damp U anyway by shear stress.
NOTE: This feature was tested for inverseDistance, trackingInverseDistance, volumeWeight cell stencils. This approach does not support the overlapping of two inset meshes on top of the background mesh.
2) Allow fringe faces away from the HOLE cells in the background domain
In the overset approach is advantageous if the interpolated cells are far removed from areas were the flow experiences large gradients. Specially next to HOLES cells created by the inset mesh on the background mesh. Initially, the INTERPOLATED cells where located next to the
HOLES cells. This created a extra burden to the solver to solve for continuity which resulted in pressure peaks.
As a result we developed a way to make a 'walk' away from the HOLE cells into the bulk of the domain in order to interpolate smoother fields.
To use a different layers for the interpolated cells In the fvSchemes is specified:
oversetInterpolation
{
method inverseDistance;
searchBox (0 0 0)(0.1 0.1 0.1);
searchBoxDivisions (130 130 1);
holeLayers 4;
useLayer 2;
}
`holeLayers` specifies how many layer out of the HOLE cells will be walked. The code will report an average ratio of the volume on each mesh, ideally one. In the obove set up the walk will be done for 4 layers and layer 2 will be used.
Tutorial :
tutorials/incompressible/overPimpleDyMFoam/simpleRotor/
tutorials/multiphase/overInterDyMFoam/floatingBody/
tutorials/multiphase/overInterDyMFoam/rigidBodyHull/
The following is a typical improvement expected on residuals for p:
![pResNoLayers](/uploads/185098ed4e69c09aa6b78271076be9ff/pResNoLayers.png)
![pRes4Layers](/uploads/7f22e45f76cc5010463f8e781bef0606/pRes4Layers.png)
NOTE: This feature was tested for inverseDistance, trackingInverseDistance, volumeWeight cell stencils
This feature was not extensibly tested to work with 1) (overlapping patches). So, the walks to find the layers could need to be reviewed.
3) Some options to improve mass conservation in overset
The overset solvers were updated to make them more consistent. Experimental keyword were removed. i.e:
massFluxInterpolation
ddtCorr
correctPhi
The new option `oversetAdjustPhi` adds a flux correction outside the pressure Eq. This flag adjusts the flux in and out of the fringes faces in the inner loop of PIMPLE.
This feature is still experimental as the outcome of this approach is still under investigation.
It proved to work in some cases. The flag is specified in the fvSolution:
tutorials/multiphase/overInterDyMFoam/simpleRotor/
PIMPLE
{
momentumPredictor no;
nOuterCorrectors 1;
nCorrectors 3;
nNonOrthogonalCorrectors 0;
oversetAdjustPhi true;
}
the mass conservation with and without oversetAdjustPhi for the above tutorial case:
![NonOuterMassCorr](/uploads/635ecca36e8ce847314f9dda3ea6974b/NonOuterMassCorr.png)
![outerMassCorr](/uploads/3929f131a440f7f1e0403eec8665a9e4/outerMassCorr.png)
The other option for mass conservation is the implicit correction specified on the field patch as:
free
{
type overset;
massCorrection true;
value uniform 300;
}
The overset patch was made an lduInterface in order to have a hook inside the linear solver to add a sum(phi) = 0 on fringe faces. It is important to note that this restriction is added in a Amul function and in the linear solvers the actual variable being converged is to the field itself but a pre-condition variable, only the first residuals are calculated using p and its flux. Therefore, the application of this restriction have some theoretical gaps. Nonetheless, the flux balance on these faces out of the linear solver DO satisfy sum(phi) = 0.
See example for overLaplacian
tutorials/basic/overLaplacianDyMFoam/1DheatTransferMassConservation/
Switching oh/off the massCorrection flag results in a better flux across the overset patch.
This approach wasn't very successful when applied to overInterFoam cases and more study might be needed, even when the sum(phi) does go to zero, the overall conservation is not fully conserved.
NOTE: It was observed that using interpolated cells as donors is possible as far as the relative number is not too large. By default `allowInterpolatedDonors` is true. But under some circumstance the user might prefer not to use them.v2212Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/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/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/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/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/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/546ENH: new tabulated anisotropic solid transport model2022-06-08T12:59:50ZKutalmış BerçinENH: new tabulated anisotropic solid transport modelEP1878
#### Summary
This feature allows users to specify tabulated anisotropic thermal conductivity
properties for solid thermodynamics with an optional coordinate system specification.
The transport model is called `tabulatedAnIso`, ...EP1878
#### Summary
This feature allows users to specify tabulated anisotropic thermal conductivity
properties for solid thermodynamics with an optional coordinate system specification.
The transport model is called `tabulatedAnIso`, and as an example, the model
is specified in `thermophysicalProperties` file as follows:
```
thermoType
{
type heSolidThermo;
mixture pureMixture;
transport tabulatedAnIso;
thermo hTabulated;
equationOfState icoPolynomial;
specie specie;
energy sensibleEnthalpy;
}
mixture
{
specie
{
molWeight 50;
}
transport
{
kappa table
(
// T kappa
( 200 (80 80 80) )
( 400 (80 80 80) )
);
// kappa <Function1<scalar>>;
}
thermodynamics
{
Hf 0;
Cp
(
( 200 450)
( 400 450)
);
Sf 0;
}
equationOfState
{
rhoCoeffs<8> (8000 0 0 0 0 0 0 0);
}
}
coordinateSystem
{
type cylindrical;
origin (0 0 0);
rotation
{
type cylindrical;
axis (1 0 0);
}
}
```
#### Tests
- [x] `linux64ClangDPInt32Opt`
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] Alltestv2206Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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 OLESEN