openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2023-02-09T12:35:30Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/592Pstream improvements for more flexibility. Non-blocking consensus exchange2023-02-09T12:35:30ZMark OLESENPstream improvements for more flexibility. Non-blocking consensus exchangeMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/591BUG: extraConvection in ATC missing a multiplication with ATClimiter2023-02-03T15:36:19ZVaggelis PapoutsisBUG: extraConvection in ATC missing a multiplication with ATClimiter### Resolved bugs (If applicable)
The bug is described in #2687
In the 'standard' and 'UaGradU' options for the ATC term of the adjoint equations, there is an option to add 'aritificial dissipation', by adding and subtracting a multip...### Resolved bugs (If applicable)
The bug is described in #2687
In the 'standard' and 'UaGradU' options for the ATC term of the adjoint equations, there is an option to add 'aritificial dissipation', by adding and subtracting a multiple of the adjoint convection term with different discretizations. The implicit part was not multiplied with the ATClimiter whereas the explicit one was, leading to mismatched contributions in the areas affected by the ATClimiter, which could affect the sensitivity derivatives.
This can be replicated using the sbend tutorial under
$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/sensitivityMaps/sbend/turbulent/lowRe/singlePoint
In the figures that follow, 'n' stands for nMask and 'e' for extraConvection in the setup of the ATC model. As 'n' increases, the sensitivity map should tend towards that of canceling the ATC everywhere. With the previous code behavior, this was not the case when $`n \neq 0, e \ne 0`$ (figure at the bottom left). The expected behavior is retrieved with the current fix (figure at the bottom right).
![sbend_ATC](/uploads/ae119cb31e9f40f288376a9f90dc9725/sbend_ATC.png)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/590ENH: wallDistAddressing: wall distance which stores addressing.2023-05-30T17:10:58ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: wallDistAddressing: wall distance which stores addressing.### Summary
In some physical models the distance-to-the-nearest-wall is used which involves calculating the nearest wall face. Some models additionally use the normal at that nearest wall face ('reflection vector') or even non-geometry ...### Summary
In some physical models the distance-to-the-nearest-wall is used which involves calculating the nearest wall face. Some models additionally use the normal at that nearest wall face ('reflection vector') or even non-geometry data (e.g. y+ in the `vanDriest` LES delta model).
The normal algorithm uses the same method (`meshWave`) to transport both the originating face centre (to decide on the nearest) and any additional properties (normal, y+). The problem with this method is that any field-dependent data (e.g. y+) needs to go through the whole algorithm even though the geometry stays constant.
In this merge request there is a new wall distance calculation method which transports the originating face centres and addressing. This addressing can then be stored and used to get any value onto the internal field.
As a test the `pipeCyclic` tutorial case was modified. In the figures below black is the original geometry with a rotational cyclic from left to right. Orange is the original geometry transformed by 90 degrees to show the effect of the rotation. Pink is a new set of wall baffles (these are the only wall faces). The green lines are from the cell centres to the nearest wall. As can be seen the cells close to the left of the original geometry find their nearest on the transformed geometry.
![nearest](/uploads/1aec1f3dde66f4d73afbd7f1569daf4c/nearest.png)
Similar, visualising the normals shows that it takes the corresponding normals of the rotated geometry
![normals](/uploads/412703afc080d28b1d8d524224d59a96/normals.png)
### Resolved bugs (If applicable)
https://develop.openfoam.com/Development/openfoam/-/issues/2648
### Details of new models (If applicable)
- `wallDistAddressing::New` instead of `wallDist::New`
- stores distance `y()` and addressing (including transformations)
- contains helper functions to map data on selected patches onto internal field
- requires https://develop.openfoam.com/Development/openfoam/-/merge_requests/589 to have named MeshObjects (if e.g. distance to non-wall patches is to be stored)
- used in `vanDriest` `LESdelta`
- used in `meshWaveAddressing` wall-distance calculation. In `system/fvSchemes`:
```
wallDist
{
method meshWaveAddressing;
nRequired true;
}
```
- debugging : set DebugSwitches for `wallDistAddressing`:
- 1 : report number of untransformed and transformed wall faces
- 2 : dump `nearest.obj` file with lines/normals to/from nearest wall face
### Risks
- slightly different behaviour at y+ 500. Before it would never visit cells surrounded by cells with y+ 500. In this version it calculates y+ everywhere and truncates afterwards. In tests we have not seen any difference.
- requires additional storage for transformations (sized with the number of wall faces and number of transformations)
- transformation support is only tested for a single transformationMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/589ENH: MeshObject: specify name (instead of typeName)2023-02-01T20:45:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: MeshObject: specify name (instead of typeName)### Summary
MeshObjects are a mesh-related singleton. Sometimes useful to have multiple versions.### Summary
MeshObjects are a mesh-related singleton. Sometimes useful to have multiple versions.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/586ENH: pureZoneMixture: different mixture properties according to cellZone2022-12-14T15:39:18ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: pureZoneMixture: different mixture properties according to cellZone### Summary
Use a different mixture on a per-cell basis.
### Details of new models (If applicable)
In the `thermoPhysicalProperties` one can now select the new `pureZoneMixture` model. It is a drop-in replacement for `pureMixture` wh...### Summary
Use a different mixture on a per-cell basis.
### Details of new models (If applicable)
In the `thermoPhysicalProperties` one can now select the new `pureZoneMixture` model. It is a drop-in replacement for `pureMixture` where the mixture properties itself are sub selected by cellZones. In below example (for a solid mesh) there are two cellZones, `heater1` and `heater2`. The second, `heater2` has slightly different properties:
```
thermoType
{
type heSolidThermo;
mixture pureZoneMixture; //pureMixture;
transport constIso;
thermo hConst;
equationOfState rhoConst;
specie specie;
energy sensibleEnthalpy;
}
mixture
{
heater1
{
specie
{
molWeight 50;
}
transport
{
kappa 80;
}
thermodynamics
{
Hf 0;
Cp 450;
}
equationOfState
{
rho 8000;
}
}
heater2
{
//- Start off from heater1 properties
${heater1}
//- Selectively overwrite properties
equationOfState
{
rho 4000;
}
}
}
```
### Risks
- the input works with the usual explicit boundary conditions (`compressible::turbulentTemperatureRadCoupledMixed`) for `chtMultiRegionFoam`. The only difference is that the per-cell properties are looked up through the cellZone the cell is in.
- the two cellZones can also not be separated (i.e. share faces) in which case attention has to be paid to the interpolation scheme (e.g. `harmonic`)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/585Misc. changes in finite-area methods2023-02-08T14:44:32ZKutalmış BerçinMisc. changes in finite-area methods#### Acknowledgement
OpenCFD would like to acknowledge and thank **Matthias Rauter** for his help and discussions. Highly appreciated.#### Acknowledgement
OpenCFD would like to acknowledge and thank **Matthias Rauter** for his help and discussions. Highly appreciated.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/579ENH: solidIsothermalReactionRate: new solid reaction rate model2022-11-29T14:31:17ZKutalmış BerçinENH: solidIsothermalReactionRate: new solid reaction rate modelEP2005, EP1629
##### Usage example
In `combustion/fireFoam/LES/simplePMMApanel/constant/panelRegion/reactions`:
```
reactions
{
_tmp_
{
#include "<constant>/panelRegion/thermo.solid"
}
charReaction
{
...EP2005, EP1629
##### Usage example
In `combustion/fireFoam/LES/simplePMMApanel/constant/panelRegion/reactions`:
```
reactions
{
_tmp_
{
#include "<constant>/panelRegion/thermo.solid"
}
charReaction
{
type irreversibleIsothermalSolidReaction;
reaction "PMMA = gas";
C <scalar>;
Tpc <scalar>;
Elat <scalar>;
Cp ${../_tmp_/PMMA/thermodynamics/Cp};
}
#remove _tmp_
}
```
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/576ENH: Added new parallelFvGeometryScheme2022-12-08T11:14:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: Added new parallelFvGeometryScheme# OpenFOAM parallel-consistent geometry calculation
This release adds a new `parallel` geometry calculation method. It is used as a wrapper around other geometry calculation methods:
```
geometry
{
type parallel;
// Op...# OpenFOAM parallel-consistent geometry calculation
This release adds a new `parallel` geometry calculation method. It is used as a wrapper around other geometry calculation methods:
```
geometry
{
type parallel;
// Optional underlying geometry calculation. Default is 'basic'.
geometry
{
type highAspectRatio;
}
}
```
It
- applies owner side face geometry (centre, normal (negated)) to the other side
- recalculates cell-based geometry of affected cells
It is mainly interesting in single-precision in that it removes the
different truncation error from circulating in different direction. This
can cause problems when calculating global transformations e.g.
```
--> FOAM FATAL ERROR: (openfoam-2206)
bad size -653174757
From void Foam::List<T>::doResize(Foam::label) [with T = Foam::vectorTensorTransform; Foam::label = int]
in file lnInclude/List.C at line 84.
#0 Foam::error::printStack(Foam::Ostream&)
#1 Foam::error::simpleExit(int, bool) at ??:?
#2 Foam::error::exiting(int, bool)
#3 Foam::List<Foam::vectorTensorTransform>::doResize(int)
#4 Foam::globalIndexAndTransform::determineTransformPermutations() at ??:?
```
Note that it does not change the point positions so any other calculated geometry (e.g. cell-closedness) might be affected.
Tutorial:
Source code:
- src/finiteVolume/fvMesh/fvGeometryScheme/parallelAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/570Updates for ensight writing2022-11-15T17:02:06ZMark OLESENUpdates for ensight writingKutalmış 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.comhttps://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/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/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 tracing2022-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/535code style, bug fixes2022-05-10T11:07:47ZMark OLESENcode style, bug fixesAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/534ENH: effectivenessHeatExchangerSource: add writeFile functionality2022-05-18T16:08:05ZKutalmış BerçinENH: effectivenessHeatExchangerSource: add writeFile functionalityEP1775
### Tests
- [x] Compilation (incl. submodules):
- [x] `linux64ClangDPInt32Opt` (clang11)
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] Alltest: No change in output with respect to the develop HEAD + n...EP1775
### Tests
- [x] Compilation (incl. submodules):
- [x] `linux64ClangDPInt32Opt` (clang11)
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] Alltest: No change in output with respect to the develop HEAD + no errorAndrew HeatherAndrew Heather