openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2021-12-08T12:08:02Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/502ENH: New schemes for non-orthogonal meshes2021-12-08T12:08:02ZKutalmış BerçinENH: New schemes for non-orthogonal meshes### Summary
**Aim:**
Improvement of numerical **stability** of **non-orthogonal** mesh simulations **only** via changes in the **diffusion operator** handling.
**(Theory) What is face non-orthogonality:**
- "The angle between the ce...### Summary
**Aim:**
Improvement of numerical **stability** of **non-orthogonal** mesh simulations **only** via changes in the **diffusion operator** handling.
**(Theory) What is face non-orthogonality:**
- "The angle between the centroid vector and the unit normal vector is the orthogonality angle." (Wimhurst, 2019)
**(Theory) Why is face non-orthogonality important:**
- Can affect the discrete diffusion operator:
- Numerical stability (hence cost)
- Level of errors
- Numerical stability
- Larger explicit treatment -> less stability
- Level of errors
- Larger corrections -> larger truncation errors
- Cannot be reduced by mesh refinement
**(Theory) What is the technical challenge in face non-orthogonality:**
- "The difficulty is to evaluate the dot product of the normal vector and the velocity gradient on the cell face." (Wimhurst, 2019)
**(Theory) Treatments in OpenFOAM:**
- Explicit correction by using an over-relaxed-type unit-normal vector decomposition
### Resolved bugs
N/A
### Methodology
**Problem definition:**
- Convergence rate
- Explicit component can become limiting factor for numerical stability
- During initial iterations, especially for steady-state runs or when starting from uniform fields in transient runs
- Yet its removal reduces accuracy
- Convergence order
- Non-orthogonality treatments are neglected at boundaries (except cyclic conditions)
- Even minor non-orthogonality on patches reduce the convergence order for cases where Dirichlet/Neumann boundary conditions are applied. (Noriega et al., 2018)
**A solution: Field relaxation**
- Field relaxation for explicit non-orthogonality components
- Under-relaxation for numerical stability
- Over-relaxation for numerical cost
- Implementation: a Laplacian scheme
- Based on an idea from `nextFoam`
- Named `relaxedNonOrthoLaplacian`
- Implementation: a surface-normal gradient scheme:
- Named `relaxedSnGrad`
**Test case:**
- The DNS study of a smooth-wall plane channel flow by (Moser et al., 1999) where the friction Reynolds number of the flow is ReTau=395.
**Metrics:**
- Numerical stability
- Simulation crashes or not
- Prediction fidelity
- Flow field predictions vs DNS statistics
**Control variable:**
<img src="/uploads/5d6921a672ee7d70d6672d48505861d5/image.png" width="50%" height="50%">
### Results
![image](/uploads/5b997d95e965d8a895b387a6d37f762d/image.png)
![image](/uploads/496cedf11adafb1a9933d0d10deca83d/image.png)
![image](/uploads/cb03fc29aece34350d7576a1c21126e6/image.png)
![image](/uploads/f3cbd51e47723f982277520b42517794/image.png)
![image](/uploads/57b268055f93e271c3766fd78be95290/image.png)
![image](/uploads/e50faee3fb0988e7f557fd5302cbf299/image.png)
### Discussion
**What happened?**
- New schemes
- Did not dampen initial residuals unlike nextFoam observations (at least for this particular case)
- Improved prediction fidelity for above 50 degrees
- Prevented simulations crashing after a certain non-orthogonality angle (above 50)
- Numerical cost
- For below-50-degree non-orthogonality cases, the runtime remained similar to that of the base
- For above-50-degree cases, the numerical cost seems to be reduced
<img src="/uploads/59a1e422f5be56ac6e631e60c7b82e22/image.png" width="50%" height="50%">
**What do the results mean in practise? (How will it change in how we do things?)**
- New schemes **may** be used
- to avoid any simulation crashes due to non-orthogonality treatments
- without affecting the fidelity of numerical predictions
- without affecting numerical cost estimations
- more tests are needed
### Risks
- No changes in existing output.
- No changes in existing user input.
### Constraints
- No finite-area numerics
- Needs extensive tests to assume safe for single-phase, multiphase and overset finite-volume applications
- No boundary treatments for Dirichlet and Neumann conditions
### 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 error
##### References
- Wimhurst, A. (2019). Mesh Non-Orthogonality. https://tinyurl.com/49b55tzw
- Wimhurst, A. (2019). Mesh Non-Orthogonality 2: The Over-Relaxed Approach https://tinyurl.com/234h7hbt
- Noriega et al. (2018). A case-study in open-source CFD code verification, Part I: Convergence rate loss diagnosis. DOI: 10.1016/j.matcom.2017.12.002v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/500ENH: New gradient scheme iterativeGaussGrad2021-12-08T11:05:44ZKutalmış BerçinENH: New gradient scheme iterativeGaussGrad### Summary
**Aim:**
Improvement of numerical **fidelity** only via improving **gradient** computations for meshes with **non-zero face skewness**.
**(Theory) What is face skewness:**
- Level of closeness of the following two spatial...### Summary
**Aim:**
Improvement of numerical **fidelity** only via improving **gradient** computations for meshes with **non-zero face skewness**.
**(Theory) What is face skewness:**
- Level of closeness of the following two spatial points:
- Face intersection of the PN vector between cell centres of an owner cell and a neighbour cell
- Face centre of the common face of the two cells
**(Theory) Why is face skewness important:**
- Prediction fidelity
- Any deviation from face centre as the face average centre reduces the second-order accuracy (i.e. non-zero face skewness)
- Hence OpenFOAM has various skewness corrections for centre-to-face interpolations
- Numerical stability
- Reduces the diagonal dominance of the discrete Poisson operator which slows down convergence. ADI (i.e. alternating-direction implicit) type preconditioners also become less effective.
**(Theory) What is the technical challenge in face skewness:**
- Omission wherever possible due to cost concerns rather than a true technical challenge
- Gradient computations are accounted for ~20% of a typical simulation
**(Theory) Treatments in OpenFOAM:**
- Many methods to quantify skewness
- OpenFOAM has its own definition
- Skewness formulations in `checkMesh` and `snappyHexMesh` are a bit different
- Various skewness corrections available
- `skewCorrectedSnGrad` surface-normal gradient scheme
- `skewCorrected` surface interpolation scheme
- No corrections on boundary skewness
- No corrections in Gauss-Green gradient computations
- Not needed for `leastSquares` and `pointLinear` based gradient schemes
### Resolved bugs
N/A
### Methodology
**Problem definition:**
- Face skewness is not accounted during any Gauss-Green gradient computations.
- Incorporation of face skewness into gradient computations **may or may not** improve the level of prediction fidelity.
**A problem solution: Iterative Gauss gradient**
- Add an outer loop around the gradient and skew-correction vector computations
- Add an optional relaxation factor inside the gradient computation
<img src="/uploads/d8930fd27b2515bb0cfd25814927918e/image.png" width="50%" height="50%">
**Test case:**
- Very difficult to design a test case where skewness is isolated from non-orthogonality
- [Manufactured solution](https://www.openfoam.com/documentation/guides/latest/doc/guide-schemes-gradient-example.html): A two-dimensional triangle-cell domain where theoretical gradient is square-root of 2 in each co-ordinate direction
**Metrics:**
- Numerical stability
- Simulation crashes or not
- Prediction fidelity - Level of discrepancy between theoretical and numerical values:
<img src="/uploads/8eb4d34c480bf6683a8814a24938c7b2/image.png" width="50%" height="50%">
- Arithmetic average of error field
- Coefficient of variation (CoV) of error field
- Relative standard deviation: std/mean
- Measure of amount of dispersion
- Low CoV: Values are close to mean
- High CoV: Values spread out over a wider range, potentially indicating outliers with respect to the mean
**Control variable:**
- Skewness is not the control variable since changing skewness also changes non-orthogonality in general
- Therefore:
- We fixed skewness and non-orthogonality with a fixed-geometry test case
- Control variable becomes the gradient scheme itself
- We quantified the performance of each gradient scheme with the chosen metric and compared them with each other
**Mesh metrics:**
![image](/uploads/69778f9a3803614e35436dd8aac054a8/image.png)
### Results
![image](/uploads/26960502a9e3d24f21e98798ab070e4b/image.png)
![image](/uploads/fe29294c40d765384b930115275d9259/image.png)
![image](/uploads/ecb33932f656ded148e1ebd2afa2218f/image.png)
![image](/uploads/5f80d7f935a35a84b5da51a4484601fe/image.png)
![image](/uploads/11ca5223abb62764749ed71a5b01dce7/image.png)
![image](/uploads/836727a0db9861dac012a9caa9355f12/image.png)
![image](/uploads/127620e5dbc5bc140a2d888e2c1419f1/image.png)
### Discussion
**What happened?**
- New iterative Gauss scheme
- Reduced errors in internal fields in comparison to other Gauss schemes
- Reduced errors in boundary fields in comparison to least square schemes
- Increasing number of iterations monotonically reduced errors
- Application of interpolation-scheme limiters increased errors
**What do the results mean in practise? (How will it change in how we do things?)**
- The new scheme **may** be used to improve prediction fidelity for gradient computations on meshes with skewness and non-orthogonality
- More tests are needed for:
- Effects of extreme levels of face skewness
- Cost estimations
- The results **do not suggest** that the new scheme can improve numerical stability
### Risks
- No changes in existing output.
- No changes in existing user input.
### Constraints
- No finite-area
- Needs extensive tests to assume safe for single-phase, multiphase and overset finite-volume applications
- No boundary treatments for Dirichlet and Neumann conditions
### 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 errorv2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/499Function1 objectRegistry access2022-02-25T06:53:57ZAndrew HeatherFunction1 objectRegistry access### Summary
Cross reference [EP 1657](https://exchange.openfoam.com/node/1657)
### Details of new models
Function1's
- `Function1` : The Function1 class can now be created using an `objectRegistry`, i.e. mesh or time databases, allow...### Summary
Cross reference [EP 1657](https://exchange.openfoam.com/node/1657)
### Details of new models
Function1's
- `Function1` : The Function1 class can now be created using an `objectRegistry`, i.e. mesh or time databases, allowing other registered objects to be retrieved, e.g. fields, models, function object state and results information
- change propagated across all `Function1` instances, e.g. boundary conditions, function objects, other `Function1s`
- `functionObjectValue` : set the `value` according to the result of a function object
- `sample` : set the `value` according to a field value
- `limitRange` : renamed to `inputValueMapper` and extended to include operations using function object results
Function object updates
- `sampledSets` : extended to store the set `min`, `max` and `average` values in its results dictionary
- `reference` : the reference value `refValue` is now set according to a `Function1` type. To recover the old behaviour (sampling a field value) users can employ the new `sample` Function1 type.
- registered fields are now prefixed - typically by `<function_object_name>:` - to avoid name collisions on registration, e.g. you can now have multiple `fieldAverage` function objects that act on the same field
Test case
- `$FOAM_TUTORIALS/incompressible/simpleFoam/simpleCar`
- Sample the pressure field using a `sets` function object; the result `average(p)` is created.
- The sample `average(p)` value is supplied to a `valueAverage` function object to perform time averaging. This creates the result `average(p)Mean`.
- The `reference` function object's `refValue` makes use of the new `functionObjectValue` Function1, where the value `average(p)Mean` is retrieved from the `average1` function object to determine the final reference field.
- A second `reference` function object to shows how to recover the old function object behaviour.
### Risks
Testing required
- `TimeFunction1` has been deprecated
- check that previous behaviours are maintained, e.g. for lagrangian injection models when using `engineTime`v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/496ENH: New suite for electrostatic deposition applications2021-11-24T18:06:40ZKutalmış BerçinENH: New suite for electrostatic deposition applications### Summary
- New suite for electrostatic deposition applications
- Solver function object: `electricPotential`: Computes the steady-state equation of charge conservation to obtain the electric potential by strictly assuming a quasi-...### Summary
- New suite for electrostatic deposition applications
- Solver function object: `electricPotential`: Computes the steady-state equation of charge conservation to obtain the electric potential by strictly assuming a quasi-static electrostatic field for single-phase and multiphase applications.
- Finite-volume boundary condition: `electrostaticDeposition`: A boundary condition to calculate electric potential (`V`) on a given boundary based on film thickness (`h`) and film resistance (`R`) fields which are updated based on a given patch-normal current density field (`jn`), Coulombic efficiency and film resistivity.
- Allowing to set:
- Minimum current density for deposition onset
- Minimum accumulative specific charge for deposition onset
- Resistance due to main body and/or pretreatment layers
- Initial electric potential
### Resolved bugs
N/A
### Details of new models (If applicable)
A showcase illustrating the verification of the `electricPotential` function object. Right: dielectric-dielectric water-air; left: conductive-dielectric water-air mixture ([López-Herrera et al., 2011](https://www.doi.org/10.1016/j.jcp.2010.11.042)).
![image](/uploads/fd8508ee81de44186bcc26d60eebc0f3/image.png)
A showcase illustrating the `electrostaticDeposition` BC: pending
### Risks
- No changes in existing output.
### Constraints
- Depletion or abrasion of material due to negative current is not allowed.
- Boundary-condition updates are not allowed during outer corrections to prevent spurious accumulation of film thickness.
- `resistivity`, `jMin`, `qMin` and `Rbody` are always non-negative.
- Quasi steady
- No electrolyte/ionic transport
- Quiescent
- Sufficiently mixed
- No magnetic field
- No electrolyte and electric field interaction
- Isotropic material and electrolyte
- No film-flow interactions
- No finite-area numerics
### Remaining issues
- Micro/nano current densities/potential differences cause numerical instabilities.
- Small diffs in patch-normal current-density values of cathode faces can lead to small diffs in incremental film thickness (Delta_h) on those faces. With the very high value of 'resistivity', the small diffs in 'Delta_h' can then lead to comparable diffs in incremental electric potential differences across patch faces.
- These differences can then be accumulated throughout a simulation, causing non-zero potential difference gradients across faces of the cathode.
- Our workaround was to round the floating-point numbers of operand variables to a given number of decimal points (default: 8 decimals) - disallow micro/nano volts, so that such accumulation could be avoided.
- However, this issue may cause numerical instabilities in more complex cases.
- Therefore, the original expressions of the formulation may need to be revisited.
- Advanced electrodeposition applications using OpenFOAM can be visited as well:
- [Kauffman et al., 2020](https://doi.org/10.3390/fluids5040240)
- [López-Herrera et al., 2011](https://www.doi.org/10.1016/j.jcp.2010.11.042)
- [Roghair et al., 2013](https://ris.utwente.nl/ws/portalfiles/portal/5676495/Roghair+Paper_final_draft_v1.pdf)
- Takayama et al., 2013, Implementation of a Model for Electroplating in
OpenFOAM.
- [Kashir et al., 2019](https://www.doi.org/10.1063/1.5050793)
- [EHDIonFOAM](https://openfoamwiki.net/index.php/Extend-bazaar/solvers/multiphase/EHDIonFOAM)v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/493ENH: new RANS model for geophysical applications2021-11-08T18:58:08ZKutalmış BerçinENH: new RANS model for geophysical applications### Summary
- ENH: kL: new RANS model for geophysical applications
- STYLE: atmosphericModels: regroup atmospheric turbulence models
- ENH: kEpsilonLopesdaCosta: enable this RANS model for compressible applications
- TUT: atmFlatTer...### Summary
- ENH: kL: new RANS model for geophysical applications
- STYLE: atmosphericModels: regroup atmospheric turbulence models
- ENH: kEpsilonLopesdaCosta: enable this RANS model for compressible applications
- TUT: atmFlatTerrain: add an example for kL RANS model
- BUG: atmFlatTerrain: fix input settings in the plot script
### Resolved bugs (If applicable)
- A small issue in `atmFlatTerrain/precursor/plot` has been corrected.
### Details of new models (If applicable)
- For a given case, the `kL` model reduces numerical costs approximately by one-third in comparison to the `kEpsilon` model for geophysical applications.
- A set of results obtained from the `atmFlatTerrain` and `atmForestStability` tutorials (left: kEpsilon, right: kL):
![image](/uploads/79d0f1db91983844da41db3af79599b6/image.png)
![image](/uploads/e1190ba19b50ddc5a093660d7f2ee4cd/image.png)
![image](/uploads/d6999f8f9d833e90acaf0a941a428c1d/image.png)
![image](/uploads/c8fbc676998046df8f8498e935ba1f21/image.png)
![image](/uploads/03df4d3859b04af634bb2c05d7391080/image.png)
![image](/uploads/d6c34c1c9e2144096b73363e8f12297c/image.png)
### Risks
- No changes in user input.
- No changes are expected in output.
- The directory structure of `src/atmosphericModels` has been changed. Therefore, the location of the directory `kEpsilonLopesdaCosta` has also been changed. Might affect few minor things for a few developers. Not crucial, IMHO.
### 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 errorv2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/488add point snapping to iso-surface topo algorithm (#2210)2021-09-27T18:25:02ZMark OLESENadd point snapping to iso-surface topo algorithm (#2210)- helps avoid the creation of small face cuts (near corners, edges)
that result in zero-size faces on output.- helps avoid the creation of small face cuts (near corners, edges)
that result in zero-size faces on output.v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/484BUG: fix yPlus predictions of nut wall functions2021-09-14T15:21:51ZKutalmış BerçinBUG: fix yPlus predictions of nut wall functions### Summary
- Corrects `y+` predictions from `nutUWallFunction`, `nutkWallFunction` and `nutLowReWallFunction`, but the internal `y+` predictions of these wall functions were kept the same in order to keep their `nut` predictions the sa...### Summary
- Corrects `y+` predictions from `nutUWallFunction`, `nutkWallFunction` and `nutLowReWallFunction`, but the internal `y+` predictions of these wall functions were kept the same in order to keep their `nut` predictions the same.
### Resolved bugs
Closes #1773, #1838, #1846, #1843
### Risks
- No changes in wall-function output.
- No changes to user input.
- New optional keyword into the `yPlus` function object: `useWallFunction`.
- Changes in the `yPlus` function object when the above nut wall functions are being used.
### Tests
- [x] Compilation: `linux64ClangDPInt32Opt`, `linux64GccDPInt32Opt`, `linux64GccSPDPInt64Debug`
- [x] Alltest: No change
- [x] [simpleFoam & rhoSimpleFoam](https://tinyurl.com/jm3n3e)
- [x] Verification: [planeChannel](https://tinyurl.com/3k3z8utc)
Verification case characteristics:
* One-dimensional smooth-wall plane channel flow, ReTau=5200
* Number of cells = 20
* nu = 0.000192827 \[m2/s\]
* The case was designed to produce => -1\*sqrt(mag(wallShearStress)) = 1
* The y1+ set (expected) = {0.05, 0.5, 1, 5, 10, 20, 30, 50, 100}
* kOmegaSST & simpleFoam
Fields of interest:
* `mag(wallShearStress)` function object correctly returns \~ 1 for all test cases.
* `yPlus` function object (min) results for `lowerWall` rounded up to 2 decimals can be seen below:
### y1+ = 0.05:
| Wall function | Pre-fix yPlus | Post-fix yPlus |
| --- | ------ |---------:|
| nutUWallFunction | **0.12** | 0.05 |
| nutkWallFunction | **0.00025** | 0.05 |
| nutUSpaldingWallFunction | 0.05 | 0.05 |
| nutUBlendedWallFunction | 0.05 | 0.05 |
| nutLowReWallFunction | 0.05 | 0.05 |
### y1+ = 0.5:
| Wall function | Pre-fix yPlus | Post-fix yPlus |
| --- | ------ |---------:|
| nutUWallFunction | **0.18** | 0.50 |
| nutkWallFunction | **0.025** | 0.50 |
| nutUSpaldingWallFunction | 0.50 | 0.50 |
| nutUBlendedWallFunction | 0.50 | 0.50 |
### y1+ = 1:
| Wall function | Pre-fix yPlus | Post-fix yPlus |
| --- | ------ |---------:|
| nutUWallFunction | **0.34** | 1.00 |
| nutkWallFunction | **0.1** | 1.00 |
| nutUSpaldingWallFunction | 1.00 | 1.00 |
| nutUBlendedWallFunction | 1.00 | 1.00 |
### y1+ = 5:
| Wall function | Pre-fix yPlus | Post-fix yPlus |
| --- | ------ |---------:|
| nutUWallFunction | **3.02** | 5.00 |
| nutkWallFunction | **2.75** | 5.00 |
| nutUSpaldingWallFunction | 5.00 | 5.00 |
| nutUBlendedWallFunction | 5.00 | 5.00 |
### y1+ = 10:
| Wall function | Pre-fix yPlus | Post-fix yPlus |
| --- | ------ |---------:|
| nutUWallFunction | **9.12** | 10.00 |
| nutkWallFunction | **8.31** | 10.00 |
| nutUSpaldingWallFunction | 10.00 | 10.00 |
| nutUBlendedWallFunction | 10.00 | 10.00 |
### y1+ = 20:
| Wall function | Pre-fix yPlus | Post-fix yPlus |
| --- | ------ |---------:|
| nutUWallFunction | 20.00 | 20.02 |
| nutkWallFunction | **19.30** | 20.01 |
| nutUSpaldingWallFunction | 20.00 | 20.00 |
| nutUBlendedWallFunction | 20.00 | 20.01 |
### y1+ = 30:
| Wall function | Pre-fix yPlus | Post-fix yPlus |
| --- | ------ |---------:|
| nutUWallFunction | 30.09 | 30.09 |
| nutkWallFunction | 29.91 | 30.12 |
| nutUSpaldingWallFunction | 30.08 | 30.08 |
| nutUBlendedWallFunction | 30.09 | 30.09 |
### y1+ = 50:
| Wall function | Pre-fix yPlus | Post-fix yPlus |
| --- | ------ |---------:|
| nutUWallFunction | 50.16 | 50.16 |
| nutkWallFunction | 50.51 | 50.19 |
| nutUSpaldingWallFunction | 50.17 | 50.17 |
| nutUBlendedWallFunction | 50.16 | 50.16 |
### y1+ = 100:
| Wall function | Pre-fix yPlus | Post-fix yPlus |
| --- | ------ |---------:|
| nutUWallFunction | 100.01 | 100.01 |
| nutkWallFunction | 100.96 | 100.01 |
| nutUSpaldingWallFunction | 100.01 | 100.01 |
| nutUBlendedWallFunction | 100.01 | 100.01 |v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/483ENH: interpolate in cylindrical coordinates: See #21452021-09-16T08:48:17ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: interpolate in cylindrical coordinates: See #2145This intercepts all vector/tensor AMI interpolations and
does the interpolation in cylindrical coordinates.
Use (component) 'coupled' linear solver to enable this in
the linear solver sweeps as well (however this is not very stable
sinc...This intercepts all vector/tensor AMI interpolations and
does the interpolation in cylindrical coordinates.
Use (component) 'coupled' linear solver to enable this in
the linear solver sweeps as well (however this is not very stable
since the vector solution is still in Cartesian coordinates -
only the AMI interpolation is in cylindrical)v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/480improve handling of multiple world communication2021-08-20T14:10:33ZMark OLESENimprove handling of multiple world communication- when attempting to connect several worlds, the overlapping communicators (or other parts) cause the simulation to bloc.- when attempting to connect several worlds, the overlapping communicators (or other parts) cause the simulation to bloc.v2112Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/478ENH: linear solvers: add variable-specific debug flags2021-08-04T09:15:33ZKutalmış BerçinENH: linear solvers: add variable-specific debug flags### Summary
* a762a311 - ENH: linear solvers: add variable-specific debug flags <Kutalmis Bercin>
* 390e7b0a - TUT: rotatingFanInRoom: perturb locationInMesh (fixes #2162) <Matej Forman>
* 7d7e012e - ENH: KirchhoffShell: simplification...### Summary
* a762a311 - ENH: linear solvers: add variable-specific debug flags <Kutalmis Bercin>
* 390e7b0a - TUT: rotatingFanInRoom: perturb locationInMesh (fixes #2162) <Matej Forman>
* 7d7e012e - ENH: KirchhoffShell: simplification of log output <Kutalmis Bercin>
Introduces a new optional keyword of label type 'log'
to linear-solver dictionaries to enable variable-specific
debug statements. For example, in fvOptions file:
solvers
{
p
{
solver GAMG;
...
log 2;
}
U
{
...
log 0;
}
}
The meanings of values of 'log' are:
log 0; <!-- no output
log 1; <!-- standard output
log 2; <!-- debug output
// values higher than 2 are expected to have no effect
### Resolved bugs (If applicable)
#2162
EP#1615 @Chiara
### Risks
This keyword does not directly affect the operations of various `DebugSwitches` and
backward compatibility has been ensured in exchange of code cleanness. The related `DebugSwitches` are:
DebugSwitches
{
SolverPerformance 0;
GAMG 0;
PCG 0;
PBiCG 0;
smoothSolver 0;
}
### Test cases
[4-ep-1615-solver-verbosity](https://tinyurl.com/4wrp4hj4)v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/477Implicit treatment of coupled boundary conditions2021-08-03T20:08:53ZSergio FerrarisImplicit treatment of coupled boundary conditions## Summary
The alternative addressing insert new internal faces on selected coupled patches. Extending the matrix addressing allows the implicit treatment of some boundary conditions. At the moment, the BCs which can be made implicit ar...## Summary
The alternative addressing insert new internal faces on selected coupled patches. Extending the matrix addressing allows the implicit treatment of some boundary conditions. At the moment, the BCs which can be made implicit are: cyclic, AMI, ACMI and mapped.
The entry `useImplicit true` is needed in the field BC. Only scalar fields can be made implicit (p, p_rgh, k, epsilon, etc). The U field **cannot** be implicit.
The top solvers are unchanged except for the cht solvers where a single he matrix is built for the multi-region case.
In the case that more than one patch is present, the user can choose which ones are treated implicitly, i.e **p** can be implicit in AMI1 and explicit in AMI2 and **k** the other way around.
Currently, there exists a limitation for parallel cases where AMI patch-pairs need to be on the same processor. For cyclics and mapped patches, the number of faces on each processor **MUST** be the same. Therefore a constraint decomposition needs to be used.
## Details of new models
The model adds a new numbering of internal/boundary coefficients and patch ID's. This is constructed at the call of the matrix.solve() - it is reset to the original addressing after solving.
The original internal/boundary coeffs are cached and used (in some cases with some extra information) to fill the coefficients on the new internal faces and/or source term on the newly formed fvMatrix.
## Tutorials
- tutorials/heatTransfer/chtMultiRegionSimpleFoam/cpuCabinet/
- tutorials/heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeaterImplicit/
- tutorials/basic/laplacianFoam/implicitAMI/
- tutorials/basic/simpleFoam/implicitAMI
- tutorials/basic/chtMultiRegionFoam/2DImplicitCyclic/
## Risks
Addressing of cells on the patches are changed, this needs to be passed to all the lduInterfaces. Use alternative lduAddressing in lduMatrix.
The coupled BCs (cyclics, AMI, mapped) which made implicit don't exist at the moment of solving the matrix. Thus, any fvOption or FO referring to this BC will **Fail**
In general terms when using the implicit approach the lduaddressing changes and therefore any matrix solve will be affected in _all top level solvers and all the linear solvers_.v2112Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/476ENH: turbulenceFields: various improvements2021-08-04T11:37:18ZKutalmış BerçinENH: turbulenceFields: various improvements- 55f61a0037 - ENH: turbulenceFields: enable custom prefix for output fields
- 8f16527a51 - BUG: turbulenceFields: unset duplicate already-registered fields
- 86f753b7bc - DOC: turbulenceFields: improve header documentation
- 189053421c...- 55f61a0037 - ENH: turbulenceFields: enable custom prefix for output fields
- 8f16527a51 - BUG: turbulenceFields: unset duplicate already-registered fields
- 86f753b7bc - DOC: turbulenceFields: improve header documentation
- 189053421c - STYLE: turbulenceFields: apply more recent OpenFOAM-coding practices
- 4243291c52 - BUG: turbulenceFields: use omega funcs of turbulence models (fixes #2132)
#### Resolved bugs
#2132
#### Test cases
[steadyBoundaryLayer](https://tinyurl.com/5fbtx82v)v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/475finiteArea: new models and solvers for films2021-07-16T16:39:50ZSergio FerrarisfiniteArea: new models and solvers for films- Adding `kinematicParcelFoam` solver:
- The original `thermoSurfaceFilm` sub-models were divided between `kinematicSurfaceFilm` and `thermoSurfaceFilm` in order to use the `surfaceFilm` model in a `kinematicCloud`.
- The film in...- Adding `kinematicParcelFoam` solver:
- The original `thermoSurfaceFilm` sub-models were divided between `kinematicSurfaceFilm` and `thermoSurfaceFilm` in order to use the `surfaceFilm` model in a `kinematicCloud`.
- The film interaction models are now in a `kinematicSurface` class which can be used in a kinematic cloud adding constant thermal properties (`p` and `T`) for some sub-models, e.g. `drySplashInteraction`, `wetSplashInteraction` etc.
- `pRef` and `Tref` were added to the `kinematicSurfaceFilm` as entry to the `regionFilm` when used with a kinematic cloud.
- In the finite area surface film model `Tref`, `pRef` are stored in `filmSubModel`.
- Film models:
- Only laminar turbulence is available for wall friction and gas shear stress. Wall friction models:
- quadraticProfile,
- linearProfile,
- DarcyWeisbach,
- ManningStrickle
- gas friction models: `Cf *(Ufilm - Ufluid)`. This would need to be improved using turbulent shear stress from the flow.
- `curvatureSepration` injection model from the film to Lagrangian particles
- minimum (`fThreshold`) force and minimum curvature (`minInvR1`) for separation were added to have more control on determining the points of film separation.
- To force wall-like BC from the fluid side the option `zeroWallVelocity true;`. Allows the film to be seen as zero U BC by the flow.
- forces: The only available extra forces (apart from gravity) is contact angle force: `perturbedTemperatureDependentContactAngle`v2112Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/474Hot fixes for v21062021-06-25T08:09:56ZAndrew HeatherHot fixes for v2106Corrected fan BC construction from dict - see #2138
- propagated valueRequired through constructor args to avoid multiple/incorrect constructor initialisations as lower levels are constructed
Added backwards compatibility for deprecated...Corrected fan BC construction from dict - see #2138
- propagated valueRequired through constructor args to avoid multiple/incorrect constructor initialisations as lower levels are constructed
Added backwards compatibility for deprecated `partialFaceAreaWeightAMI` class
- functionality now available using `faceAreaWeightAMI`
- added alias to AMI run-time selection tablev2106Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/473TUT: multiphase: replace boatAndPropeller with rigidBodyHull2021-06-22T22:42:07ZKutalmış BerçinTUT: multiphase: replace boatAndPropeller with rigidBodyHull`Alltest` & `Allrun` good.`Alltest` & `Allrun` good.v2106Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/471ENH: Adding new permeable boundary conditions and a tutorial2021-06-17T21:01:28ZSergio FerrarisENH: Adding new permeable boundary conditions and a tutorial- 4d2e6e63f9b99d97dc83d2ee7b41d0fc47030d88: ENH: Adding new permeable boundary conditions
- `prghPermeableAlphaTotalPressure` for `p_rgh`
- `pressurePermeableAlphaInletOutletVelocity` for `U`
- new helper class for pressure-r...- 4d2e6e63f9b99d97dc83d2ee7b41d0fc47030d88: ENH: Adding new permeable boundary conditions
- `prghPermeableAlphaTotalPressure` for `p_rgh`
- `pressurePermeableAlphaInletOutletVelocity` for `U`
- new helper class for pressure-related BCs: `updateableSnGrad`
- 2a3b41e523cba5490a7cbd408e92a5c964e970a2: TUT: new multiphase tutorial: `damBreakPermeable`v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/470ENH: Added new multiRegion function object2021-06-16T11:48:22ZAndrew HeatherENH: Added new multiRegion function objectWrapper that clones the supplied object for each region.
Simplifies setting up identical post-processing requirements for multi-
region cases. Applies the supplied function to all regions by default.
Example of function object specific...Wrapper that clones the supplied object for each region.
Simplifies setting up identical post-processing requirements for multi-
region cases. Applies the supplied function to all regions by default.
Example of function object specification:
multiRegion
{
type multiRegion;
libs (utilityFunctionObjects);
...
function
{
// Actual object specification
type fieldMinMax;
libs (fieldFunctionObjects);
fields (<field1> .. <fieldN>);
}
// Optional entries
regions (region1 region2);
}
Where the entries comprise:
Property | Description | Required | Default value
type | Type name: multiRegion | yes |
function | Function object sub-dictionary | yes |
regions | List of region names | no | allv2106Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/469ENH: new multiFieldValue function object2021-06-16T10:14:30ZAndrew HeatherENH: new multiFieldValue function objectComputes a selected operation between multiple `fieldValue` function objects.
The operation is applied to all results of each `fieldValue` object.
Note
- Each object must generate the same number and type of results.
Usage
Minima...Computes a selected operation between multiple `fieldValue` function objects.
The operation is applied to all results of each `fieldValue` object.
Note
- Each object must generate the same number and type of results.
Usage
Minimal example by using \c system/controlDict.functions:
multiFieldValue1
{
// Mandatory entries (unmodifiable)
type multiFieldValue;
libs (fieldFunctionObjects);
// Mandatory entries (runtime modifiable)
operation subtract;
// List of fieldValue function objects as dictionaries
functions
{
region1
{
...
}
region2
{
...
}
...
regionN
{
...
}
}
// Optional (inherited) entries
...
}
where the entries mean:
Property | Description | Type | Req'd | Dflt
-------------|-------------------------------------|------|-------|------
type | Type name: `multiFieldValue` | word | yes | -
libs | Library name: `fieldFunctionObjects` | word | yes | -
operation | Operation type to apply to values | word | yes | -
functions | List of `fieldValue` function objects | dict | yes | -
Options for the \c operation entry:
add | add
subtract | subtract
min | minimum
max | maximum
average | average
**Deprecated `fieldValueDelta`**
The `fieldValueDelta` function object was originally written to compute the difference between two fieldValue-type function objects. `The multiFieldValue` object name better describes its purpose whilst being able to operate on an arbitrary number of fieldValue-type objects.v2106Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/468AMI improvements2021-06-18T10:32:20ZAndrew HeatherAMI improvements- Added new faceAreaWeightAMI2D AMIMethod:
- performs intersection using a new 2D triangle class;
- candidate face matches set using an AABBTree method (vs advancing front for
faceAreaWeightAMI).
- Use by setting the AMIMethod...- Added new faceAreaWeightAMI2D AMIMethod:
- performs intersection using a new 2D triangle class;
- candidate face matches set using an AABBTree method (vs advancing front for
faceAreaWeightAMI).
- Use by setting the AMIMethod entry when specifying the AMI in the
constant/polyMesh/boundary file, e.g.
AMI
{
type cyclicACMI;
AMIMethod faceAreaWeightAMI2D; // new method
Cbb 0.1; // optional coefficient
nFaces 1000;
startFace 100000;
matchTolerance 0.0001;
transform noOrdering;
neighbourPatch AMI1;
nonOverlapPatch AMI1_non_overlap;
}
- The optional Cbb coeffcient controls the size of the bounding box used when
looking for candidate pairs; the value of 0.1 is the default and worked well
for a large range of test cases. For badly matched AMI patches this may need
to be increased.
- Deprecated the partialFaceAreaWeightAMI class - primarily used by ACMI:
- functionality now offered by the AMI variants.
- ~~NOTE: both AABBTree and octree variants included for review; ***ONLY 1 METHOD TO BE ADDED***~~
EDIT: octree method remoedv2106Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/467ENH: Added under-relaxation to jump conditions2021-06-14T15:34:44ZAndrew HeatherENH: Added under-relaxation to jump conditionsUpdates to the jump boundary conditions
- provide an optional minimum jump value
```
plane
{
type fan;
patchType cyclic;
jump uniform 0;
value uniform 0;
...Updates to the jump boundary conditions
- provide an optional minimum jump value
```
plane
{
type fan;
patchType cyclic;
jump uniform 0;
value uniform 0;
uniformJump false;
jumpTable ( (1000 0) (-200 1) (20 2) (-0.75 3) );
// Optional minimum jump value
minJump 0;
}
```
- add possibility to under relax the jump value. Currently only applied to the fanFvPatchField where it can be useful for steady, non-uniform jump set-ups to avoid instabilities/checker-boarding, e.g.
```
plane
{
type fan;
patchType cyclic;
jump uniform 0;
value uniform 0;
uniformJump false;
// Optional under-relaxation
relax 0.2;
...
}
```
Current (old) behaviour
![noRelax-minJump-GREAT](/uploads/47d41219028e2705ac296c9a0e3d513d/noRelax-minJump-GREAT.png)
New behaviour with under-relaxation
![relax0dot2-minJump-GREAT](/uploads/ccbf2edf3627bd960dd9bd6419815f5e/relax0dot2-minJump-GREAT.png)v2106Sergio FerrarisSergio Ferraris