openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2023-06-28T15:35:56Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/609ENH: turbulentTemperatureRadCoupledMixed: add postprocessing elements2023-06-28T15:35:56ZKutalmış BerçinENH: turbulentTemperatureRadCoupledMixed: add postprocessing elements#### Summary
Two postprocessing elements were added into the `turbulentTemperatureRadCoupledMixed` BC:
- Add the `writeFile` functionality.
- Enable the calculation of heat-transfer coefficient fields.
#### Risks
- No change in existi...#### Summary
Two postprocessing elements were added into the `turbulentTemperatureRadCoupledMixed` BC:
- Add the `writeFile` functionality.
- Enable the calculation of heat-transfer coefficient fields.
#### Risks
- No change in existing input.
- Two new optional keywords: `logInterval` and `verbose` (see the header file.)
- No change in existing output.
#### Metadata
- [x] linux64ClangDPInt32Opt (clang13)
- [ ] linux64GccDPInt32Opt
- [ ] linux64GccSPDPInt64Debug
- [x] Alltest: No new error/No change in existing output
- [x] Test case: [MR608-02Jun2023-test.zip](/uploads/4882c4cf357845300397bdc02efe54c5/MR608-02Jun2023-test.zip)v2306Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/613ENH: sixDoF: add max/min angle constraints to the axis constraint2023-06-14T14:30:57ZKutalmış BerçinENH: sixDoF: add max/min angle constraints to the axis constraint#### Summary
The `axis` constraint imposes an orientation limitation where bodies
are restricted to rotate only around a fixed axis.
The set of commits optionally introduces the inclusion of maximum and
minimum rotation angle constrain...#### Summary
The `axis` constraint imposes an orientation limitation where bodies
are restricted to rotate only around a fixed axis.
The set of commits optionally introduces the inclusion of maximum and
minimum rotation angle constraints to the `axis` constraint.
##### Details
The following plot shows the rotation angle of the body modelled in "test-case.zip" with respect to the reference orientation. The inflow changes at t=2[s] and =4.5[s] to move the body in the opposite directions:
- Between t=0-2[s], the flow rotates the body in the clockwise direction. However, the body is limited by 0.15[rad] clockwise rotation wrt the ref orientation.
- Note that the ref orientation is at +0.25[rad] at t=0[s].
- Between t=2-4.5[s], the flow rotates the body in the counterclockwise direction. The body is limited to 0.05[rad] counterclockwise rotation wrt the ref orientation.
- Note that the body wants to rotate in the clockwise direction for sometime due to (I assume) some wake physics (or I need to reping the body to another point) between 3.5-4.5[s].
- Between t=4.5-8.5[s], the flow rotates the body in the clockwise direction, but this time, the rotation is limited to -0.1[rad] clockwise rotation.
<img src="/uploads/5a350ae505a61a12432a2011a3df377a/plot_theta_0.png" width="40%" height="40%">
#### Risks
- No change in existing input/output.
#### Metadata
- [x] linux64ClangDPInt32Opt (clang13)
- [ ] linux64GccDPInt32Opt
- [ ] linux64GccSPDPInt64Debug
- [ ] Alltest: No new error/No change in existing output
- [x] Test case: [test-case.zip](/uploads/42697e3e56b4f2faa249f7e5ebd5c976/test-case.zip)v2306Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/611ENH: finiteArea: enable gradient caches2023-06-14T14:22:10ZKutalmış BerçinENH: finiteArea: enable gradient caches#### Summary
The gradient chaching functionality is enabled for the finite-area framework.
Example usage in `system/faSolution`:
```
cache
{ ...#### Summary
The gradient chaching functionality is enabled for the finite-area framework.
Example usage in `system/faSolution`:
```
cache
{
grad(h);
grad(Us);
}
```
#### Risks
- No change in existing input/output.
#### Metadata
- [x] linux64ClangDPInt32Opt (clang13)
- [ ] linux64GccDPInt32Opt
- [ ] linux64GccSPDPInt64Debug
- [ ] Alltest: No new error/No change in existing output
- [x] Test case: `$FOAM_TUTORIALS/finiteArea/liquidFilmFoam/cylinder`v2306Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/608Feature distributed DIC/DILU preconditioners2023-06-01T16:21:01ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comFeature distributed DIC/DILU preconditioners### Summary
The current DIC/DILU preconditioners operate on the local data only. This merge implements parallel versions of these using a processor-colouring strategy where data from lower coloured processors is included in the forward ...### Summary
The current DIC/DILU preconditioners operate on the local data only. This merge implements parallel versions of these using a processor-colouring strategy where data from lower coloured processors is included in the forward sweep and (data from) higher coloured processors in the backwards sweep. This generally leads to lower number of PCG sweeps so less global reductions at the cost of more halo swaps.
### Details of new models (If applicable)
Implements two new preconditioners: `distributedDIC` and `distributedDILU`. Both can be used in a top-level `PCG` or `PBiCGStab` solver or for the coarsest-level in `GAMG`:
```
p
{
solver GAMG;
// Explicit specify solver for coarse-level correction to override
// preconditioner
coarsestLevelCorr
{
solver PCG;
preconditioner distributedDIC;
}
}
```
### Risks
- for extreme decompositions (e.g. using `random`) might increase simulation time
- increased memory usage - allocates buffers for all remote data
- construction of preconditioners requires halo-swaps (for inverse of diagonal) so might not be cost-effective for low numbers of PCG sweeps
- communication pattern now has cross-overs - order of receiving is not the same as order of sending. Solved by using different message tags.
- effectiveness depends on cost of reduction v.s. halo-swapsAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/595ENH: ParticleHistogram: refactor PatchParticleHistogram function object2023-06-01T08:24:31ZKutalmış BerçinENH: ParticleHistogram: refactor PatchParticleHistogram function object#### Summary
- enable 'faceZone' support for the function objects below.
- introduce 'cloudFunctionObjectTools' to simplify collection of particle info
on patches or face zones.
- enable 'writeFile' support to better control file outp...#### Summary
- enable 'faceZone' support for the function objects below.
- introduce 'cloudFunctionObjectTools' to simplify collection of particle info
on patches or face zones.
- enable 'writeFile' support to better control file output.
- rename 'PatchParticleHistogram' as 'ParticleHistogram', and 'PatchPostProcessing' as 'ParticlePostProcessing' for better clarity.
#### Resolved bugs
#1808
#### Risks
- User input:
- Names of FOs have been changed
- No change in existing output.
#### Meta-data
* EP2071
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error/No change in existing outputAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/600Restarting local agglomeration inside masterCoarsets processor agglomeration2023-06-01T08:19:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comRestarting local agglomeration inside masterCoarsets processor agglomeration### Summary
Continue agglomeration after master-coarsest processor agglomeration
### Details of new models (If applicable)
```
p
{
solver GAMG;
..
smoother GaussSeidel;
//- Local agglomeration paramet...### Summary
Continue agglomeration after master-coarsest processor agglomeration
### Details of new models (If applicable)
```
p
{
solver GAMG;
..
smoother GaussSeidel;
//- Local agglomeration parameters
nCellsInCoarsestLevel 1;
//- Processor-agglomeration parameters
processorAgglomerator masterCoarsest;
//- Indicate that local agglomeration needs to be restarted
nCellsInMasterLevel 1;
}
```
### Risks
- backwards compatible
- not extensively testedAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/606ENH: coupled: enforce consistency. See #27832023-06-01T08:25:57ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: coupled: enforce consistency. See #2783### Summary
Make sure that constraints (processor, cyclic etc) are performed at all steps.
### Resolved bugs (If applicable)
#2783
### Details of new models (If applicable)
### Risks
Differing behaviour on interpolating patch ty...### Summary
Make sure that constraints (processor, cyclic etc) are performed at all steps.
### Resolved bugs (If applicable)
#2783
### Details of new models (If applicable)
### Risks
Differing behaviour on interpolating patch types (cyclic, cyclicAMI)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/598ENH: forces: avoid redundant volumetric operations2023-06-06T07:29:08ZKutalmış BerçinENH: forces: avoid redundant volumetric operations#### Problem
It has been observed that employing the `forces` and `forceCoeffs` function objects in several simulations causes a slowdown ranging from 2 to 10%.
The culprits found were:
- Calculation of velocity gradient
- Redundant c...#### Problem
It has been observed that employing the `forces` and `forceCoeffs` function objects in several simulations causes a slowdown ranging from 2 to 10%.
The culprits found were:
- Calculation of velocity gradient
- Redundant calculations performed for various internal fields
#### Solution
- It is recommended to cache 'grad(U)' whenever using `forces` and `forcesCoeffs` function objects.
- The recent commits have eliminated unnecessary computations for the internal field of `devRhoReff`.
- Tests using the `simpleCar` tutorial ('grad(U)' was cached) produced the following 'profiling' figures:
![image](/uploads/c4b1c39cde976ad13cec2ee835523bf1/image.png)
- Tests using an industrial case ('grad(U)' was cached) reduced the `functionObjects.execute()` from ~72[s] to ~23[s].
#### Meta-data
* EP2065
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error/No change in existing output
* [x] No output change in all operating conditions (e.g. direct force intensity, porosity, compressible flows etc.)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/602ENH: Coulomb: new particle electric force model calculating Coulomb forces2023-05-15T15:35:14ZKutalmış BerçinENH: Coulomb: new particle electric force model calculating Coulomb forces#### Problem
OpenFOAM lacked a Lagrangian model for electrostatic forces acting on particles based on their diameters.
#### Solution
The present commits furnish a model of this kind, along with essential underlying changes in the 'ele...#### Problem
OpenFOAM lacked a Lagrangian model for electrostatic forces acting on particles based on their diameters.
#### Solution
The present commits furnish a model of this kind, along with essential underlying changes in the 'electricPotential' function object for evaluating the electric field. The coupling is one way (for now).
#### Meta-data
* EP1880
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error/No change in existing output
* [x] No output change in all operating conditions except the following:
- The electric field is computed according to the new Boolean input `electricField` instead of `writeDerivedFields` toogle.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/603ENH: parProfiling: profile linear solver only2023-05-03T19:04:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: parProfiling: profile linear solver only### Summary
Wrapper for linear solver to enable/disable parProfiling so it profiles only the linear solver.
### Details of new models (If applicable)
See `tutorials/IO/cavity_parProfiling`### Summary
Wrapper for linear solver to enable/disable parProfiling so it profiles only the linear solver.
### Details of new models (If applicable)
See `tutorials/IO/cavity_parProfiling`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/601Optimization to ldu Matrix2023-05-10T10:10:40ZAlon ZameretOptimization to ldu Matrix## 1 Goal
The goal of this change is to improve the sparse solver in OpenFOAM in terms of computational efficiency and communication reduction.
The related modifications come in three categories:
- remove the redundant codes in **symG...## 1 Goal
The goal of this change is to improve the sparse solver in OpenFOAM in terms of computational efficiency and communication reduction.
The related modifications come in three categories:
- remove the redundant codes in **symGaussSeidelSmoother.C**.
- fuse the “ACf = Ax” with “coarseSources -= ACF” to get “coarseSources -=Ax” codes in **GAMGSolverSolve.C**.
- reduce the number of “Allreduce” in **PCG.C**.
## 2 Proposed Change and Results
### 2.1 symGaussSeidelSmoother.C
The symGaussSeidel runs the following algorithm:
- Forward: $x_i^{k+1}=\frac{1}{a_{ii}} (b-∑_{j=1}^{i-1}a_{ij} x_j^{k+1} -∑_{j=i+1}^na_{ij} x_j^k)$
- Backward: $x_i^{k+2}=\frac{1}{a_{ii}} (b-∑_{j=1}^{i-1}a_{ij} x_j^{k+1} -∑_{j=i+1}^na_{ij} x_j^{k+2})$
The realization in OpenFOAM is as follows:
![symgs](/uploads/e45b8885d2b60ea47033e38cd918a749/symgs.png)
We can see that the last step, i.e. $bPrime=bPrime-∑_{j=i+1}^n a_{ij} x_i^{k+2} $, is redundant. Mapping to the code realization, we can get the “distribute neighbor side …” step is redundant as long as forall facei > ownStartPtr[celli], uPtr[facei] > celli.
We test the modification on cavity 256*512 case. The results show that symgs operation improves by 5%,and the results keeps the same.
- Orginal: Total 28.19s , symGS time = 28.19*62.32% =17.568s
![symgsResult1](/uploads/7b0490eff481b9cf945de2ec4824bef9/symgsResult1.png)
- Modified: Total 27.39s , symGS time = 27.39*61.16% =16.75s
![symgsResult2](/uploads/1cfa3235edb4fae17fbffe39e5a52bf6/symgsResult2.png)
### 2.2 GAMGSolverSolve.C
Original code writes “ACf = Ax” together with “coarseSources -= ACF”. We can combine them together to get “coarseSources -=Ax”.
Furthermore, “ACF” is not used here. We can move the declaration of “ACF” to where it is needed. I think the declaration of ACF can be further simplified, which is done here.
The fusion and the move of the declaration will improve the performance (not much, but better than none) and reduce the kernel used.
### 2.3 PCG.C
The original PCG have three “Allreduce” procedure, which is the most time-consuming part when running large scale system. Note that the last “Allreduce” procedure is used to calculate the residual for convergence. Then we can move the last “Allreduce” procedure to the next iteration, and combine it with the first “Allreduce” procedure. The figure illustrates the aforementioned change.
![PCG](/uploads/3f289551df29e8425fe39809c828948a/PCG.png)
The proposed change is able to reduce iterNo/3 number of “Allreduce” process and iterNo number of “r” variable load at the cost of one more precondition. (iterNo:the number of iterations)
The proposed change will improve performance if
- run PCG for solving coarsest mesh.
- run PCG with preconditioner DIC/diagonal/none. (test with cavity512*512, Kunpeng 920 128cores, DIC preconditioned PCG)
- Orginal: Total 2.46s , shared memory MPI = 2.46*33.92% =0.83s
![PCGResult1](/uploads/1b9246942756e2ae021394605516f8f0/PCGResult1.png)
- Modified: Total 2.11s , shared memory MPI = 2.11*28.38% =0.6s
![PCGResult2](/uploads/33c64e8bd7f398a6557b80d29b9482f4/PCGResult2.png)
- run PCG with preconditioner GAMG with many cores or many iterations.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/599ENH: multiLevel: native scotch implementation of multi-level2023-05-09T13:05:16ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: multiLevel: native scotch implementation of multi-level### Summary
Support multi-level type decomposition using native scotch functionality. multi-level decomposition is e.g. used when processor-processor communication is more expensive if the two processors are not on the same node. Hence ...### Summary
Support multi-level type decomposition using native scotch functionality. multi-level decomposition is e.g. used when processor-processor communication is more expensive if the two processors are not on the same node. Hence it makes sense to minimise 'cuts' between nodes at the cost of increasing 'cuts' between processors on the same node. This is supported natively in scotch by specifying different costs.
### Resolved bugs (If applicable)
### Details of new models (If applicable)
Specify a hierarchy of decompositions. Specify different weights traversing the hierarchy.
```
numberOfSubdomains 2048;
coeffs
{
// Divide into 64 nodes, each of 32 cores
domains (64 32);
// Inside a nodes the communication weight is 1% of that inbetween nodes
domainWeights (1 0.01);
}
```
Alternatively the first-level decomposition can be left out by assuming weights are 1 for that level:
````
numberOfSubdomains 2048;
coeffs
{
// Divide into 2048/32=64 nodes
domains (32);
// Inside a node the communication weight is 1% of that inbetween nodes
domainWeights (0.01);
}
```
### RisksAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/597ENH: improved point-cell and cell-point topology methods (#2715)2023-03-03T16:36:57ZMark OLESENENH: improved point-cell and cell-point topology methods (#2715)- for OpenFOAM-v2212 and earlier cellPoints() were constructed
from pointCells(), but this is slower than constructing
pointCells() from cellPoints().
Some of the slowness is due to allocations associated with
cells::labels(), b...- for OpenFOAM-v2212 and earlier cellPoints() were constructed
from pointCells(), but this is slower than constructing
pointCells() from cellPoints().
Some of the slowness is due to allocations associated with
cells::labels(), but a large amount of slowness is the duplicate
point avoidance. Since this is being done for many points/cells
at once, using a bitSet for managing the duplicates amortizes
quickly
- now construct cellPoints() from cached pointCells(), otherwise
construct manually (using bitSet/DynamicList for bookkeeping)
- construct pointCells() from cached cellPoints(), or cached
pointFaces(), otherwise manually.
Code Contribution: Alon Zameret
Co-authored-by: Mark OlesenMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/596Improved point-cell and cell-point topology methods2023-03-03T16:41:20ZAlon ZameretImproved point-cell and cell-point topology methods# Goal
The goal of this change is to reduce the runtime of the `pointCells()` and `cellPoints()` methods in the `primitiveMesh` class, which calculate the point-to-cell and cell-to-point addressing, respectively.
# Proposed Change
The...# Goal
The goal of this change is to reduce the runtime of the `pointCells()` and `cellPoints()` methods in the `primitiveMesh` class, which calculate the point-to-cell and cell-to-point addressing, respectively.
# Proposed Change
The `pointCells()` currently calculates the topology using the private method `calcPointCells()`, which utilizes the method `labels()` in the `cell` class. This method introduces significant overhead and reduces performance. The `cellPoints()` method currently calls the `pointCell()` method and inverts the result.
The proposed solution implements the `cellPoints()` method directly using a more efficient algorithm that makes use of the `bitset` data class to mark points that have already been found. Then, the `pointCells()` method is implemented by calling `cellPoints()` and inverting the result. As can be seen below, our implementation improves performance in all cases, even if the user only wants the point-cell topology.
# Results
The speedup values were calculated by running both the current version and the new version on structured cube meshes of varying sizes. It can be seen that the speedup remains constant among all the different mesh sizes.
In the testing, the meshes began without either one of the topologies present. Then 3 different cases were tested:
1. The user wants only point-cell topology
- Speedup = 1.4x
2. The user wants only cell-point topology
- Speedup = 2.4x
3. The user wants both topologies
- Speedup = 1.7x
![Screenshot](/uploads/f817bd3f389edff96fe6c9a62d6146b5/Screenshot.png)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/593Field functions for lerp and clamp. Add clamping as Field methods2023-02-21T09:17:59ZMark OLESENField functions for lerp and clamp. Add clamping as Field methodsTo improve data locality and simplify calling code, now have `lerp()` and `clamp()` as free functions working on fields. Both can be composed as a SIMD type of operation (with three operands) and applied within the fields loops instead o...To improve data locality and simplify calling code, now have `lerp()` and `clamp()` as free functions working on fields. Both can be composed as a SIMD type of operation (with three operands) and applied within the fields loops instead of being composed as separate field operations.
- Having `lerp` turns out to only be moderately useful, since most of the schemes have already unrolled the operation inside. However, it is still quite convenient when composing (for example) mixed boundary conditions or combining patch internal and neighbour values.
- The `clamp` method is used in several more places, quite commonly in multi-phase routines to enforce a strict 0-1 boundness.
Since clamping of field values is a quite useful property, in-place clamping has been added as field methods directly:
- clamp_min(...), clamp_max(...), clamp_range(...)
The frequently required 0-1 bounding can be use succinctly with the `zero_one` dispatch tag. For example,
```
alpha.clamp_range(zero_one{});
```
Tip: with flow switching (eg, inlet/outlet) the `lerp` function can be combined with `pos0` to define a selector. Eg,
```
lerp(a, b, pos0(phi))
// vs.
a*neg(phi) + b * pos0(phi)
```v2306Andrew HeatherAndrew Heatherhttps://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/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/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/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 OLESEN