openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2021-11-05T13:08:53Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/485ENH: proudmanAcousticPower - extended to operate on mean turbulence fields2021-11-05T13:08:53ZAndrew HeatherENH: proudmanAcousticPower - extended to operate on mean turbulence fieldsThe `proudmanAcousticPower` function object has been updated with the option to operate on user-supplied turbulence fields.
Example using mean turbulence fields (mean fields should be available e.g. from a fieldAverage function object)...The `proudmanAcousticPower` function object has been updated with the option to operate on user-supplied turbulence fields.
Example using mean turbulence fields (mean fields should be available e.g. from a fieldAverage function object)
proudmanAcousticPower1
{
// Mandatory entries (unmodifiable)
type proudmanAcousticPower;
libs (fieldFunctionObjects);
...
// Turbulence field names (if not retrieved from the turb model)
k kMean;
epsilon epsilonMean;
omega none; // omegaMean
}v2206Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/486ENH: Improve the handling of wall-function coefficients and blenders2022-05-18T16:05:21ZKutalmış BerçinENH: Improve the handling of wall-function coefficients and blenders### Summary
- Fixes #1457 and #1966
- Improves the handling of wall-function coefficients and blenders
- Standardises the output of wall-function entries
- Removes redundant and inconsistent virtual specifiers
- Modernises the code sty...### Summary
- Fixes #1457 and #1966
- Improves the handling of wall-function coefficients and blenders
- Standardises the output of wall-function entries
- Removes redundant and inconsistent virtual specifiers
- Modernises the code style
- Improves header file documentation
- Removes the blending option `BINOMIAL2` from `omegaWallFunction`
### Resolved bugs
Closes #1457, #1966
### Risks
- Silently replaces the **default** blending option `BINOMIAL2` of the `omegaWallFunction` with the option `BINOMIAL` with `n=2`. In theory, both expressions are the same. Yet numerically, both expressions will yield negligible differences in floating-point decimals.
### 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
- [x] Verification: No change in output [rhoSimpleFoam/simpleFoam/buoyantBoussinesqSimpleFoam](https://develop.openfoam.com/OpenCFD/OpenFOAM-test/-/tree/test-wall-functions/tests-for-v2206/regressions-wall-functions)v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/487ENH: Regroup and unify various virtual functions in laminar/RAS/LES models2021-10-22T16:29:14ZKutalmış BerçinENH: Regroup and unify various virtual functions in laminar/RAS/LES models### Summary
- Regroup and unify various virtual functions in laminar/RAS/LES models
### Resolved bugs
N/A
### Risks
- No changes to user input.
- No changes in output.
- From now on, `Ce` is printed out to streams only when it i...### Summary
- Regroup and unify various virtual functions in laminar/RAS/LES models
### Resolved bugs
N/A
### Risks
- No changes to user input.
- No changes in output.
- From now on, `Ce` is printed out to streams only when it is specified in `turbulenceProperties` (similar to `kMin`).
- Few models had been specifying the boundary conditions of helper functions: `kOmegaSSTBase`, `kOmegaSST`. This has been removed. No detrimental effects are expected.
### 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 Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/488add point snapping to iso-surface topo algorithm (#2210)2022-12-12T16:16:46ZMark 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/489BUG: 2021-1: Various bug fixes and developments2021-10-05T10:47:23ZKutalmış BerçinBUG: 2021-1: Various bug fixes and developments### Resolved bugs
#1513 #2067 #2202 #2214
### Risks
* No changes in output
* No changes in mandatory user input.
### Tests
* [x] Compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Op...### Resolved bugs
#1513 #2067 #2202 #2214
### Risks
* No changes in output
* No changes in mandatory user input.
### 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 Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/490parallel construct finiteArea with arbitrary connections2021-11-05T21:28:48ZMark OLESENparallel construct finiteArea with arbitrary connectionsReplace the old patch/patch matching style with a more general edge-based synchronisation and matching that appears to handle the corner cases inherently. The internal communication overhead is essentially unchanged, and the logic is si...Replace the old patch/patch matching style with a more general edge-based synchronisation and matching that appears to handle the corner cases inherently. The internal communication overhead is essentially unchanged, and the logic is simpler.https://develop.openfoam.com/Development/openfoam/-/merge_requests/491ENH: decomposePar: cyclicAMI in constraints. Fixes #22422021-10-20T15:40:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: decomposePar: cyclicAMI in constraints. Fixes #2242The `preservePatches` constraint in `decomposeParDict` can be used to keep owner and neighbour cells of coupled patches on the same processor. It previously only handled one-to-one coupling (`cyclic`, `processor`) but has been extended t...The `preservePatches` constraint in `decomposeParDict` can be used to keep owner and neighbour cells of coupled patches on the same processor. It previously only handled one-to-one coupling (`cyclic`, `processor`) but has been extended to handle many-to-one coupling (`cyclicAMI`, `cyclicACMI`).
Without syncing across (in green) cyclicAMI:
![cellDist_random_preservePatches_noAMI](/uploads/dfca803611967a7251d0959b5e4e8cfb/cellDist_random_preservePatches_noAMI.png)
With syncing across (in green) cyclicAMI:
![cellDist_random_preservePatches_new](/uploads/49cb241633d8f7c51f67d8f6492e437b/cellDist_random_preservePatches_new.png)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/492BUG: 2021-2: Various bug fixes and developments2021-12-09T18:49:21ZKutalmış BerçinBUG: 2021-2: Various bug fixes and developments### Resolved bugs
#2228 #2186 #2026 #2178 #1171 #2243 #2069
### Risks
* No changes in output
* No changes in mandatory user input.
### Tests
* [x] Compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `l...### Resolved bugs
#2228 #2186 #2026 #2178 #1171 #2243 #2069
### Risks
* No changes in output
* No changes in mandatory user input.
### 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 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/494BUG: collated: threaded writing accesses out-of-scope. Fixes #2257.2021-11-02T14:26:31ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: collated: threaded writing accesses out-of-scope. Fixes #2257.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/495Improve the Lagrangian drag models2022-05-30T08:25:58ZKutalmış BerçinImprove the Lagrangian drag models### Summary
- Remove the redundant CdRe function in `PlessisMasliyah`
- Improve header file documentation
- Modernise the code style
### Resolved bugs
N/A
### Risks
- No changes in output
- No changes to user input
### Tests
- ...### Summary
- Remove the redundant CdRe function in `PlessisMasliyah`
- Improve header file documentation
- Modernise the code style
### Resolved bugs
N/A
### Risks
- No changes in output
- No changes to user input
### Tests
- [x] Compilation (incl. submodules):
- [x] `linux64ClangDPInt32Opt` (clang11)
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] Alltest: No errorv2206Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/497ENH: fvSolution: allow Function1 for all scalars2021-11-10T19:06:50ZKutalmış BerçinENH: fvSolution: allow Function1 for all scalars### Summary
- Allows the usage of `Function1` for scalar entities within `fvSolution`, e.g. for `relaxationFactors`.
### Resolved bugs
N/A
### Risks
* No changes in output.
* No changes in existing user input.
### Tests
* [x] C...### Summary
- Allows the usage of `Function1` for scalar entities within `fvSolution`, e.g. for `relaxationFactors`.
### Resolved bugs
N/A
### Risks
* No changes in output.
* No changes in existing user input.
### Tests
* [x] Compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No error
* [x] Performance testsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/498ENH: report dictionary defaults with Executable prefix2021-11-17T17:33:02ZMark OLESENENH: report dictionary defaults with Executable prefix- provides better context when default values are accessed from
a dictionary than reporting a source file location.
Requirements as per EP1546.
Typically called as follows:
application -dry-run -info-switch writeOptionalEntries
...- provides better context when default values are accessed from
a dictionary than reporting a source file location.
Requirements as per EP1546.
Typically called as follows:
application -dry-run -info-switch writeOptionalEntries
Normally not advisable to run in non-dry-run mode (will flood the output).Andrew 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/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/501Updates for expressions to improve robustness and support functions, external context etc.2021-11-26T12:16:46ZMark OLESENUpdates for expressions to improve robustness and support functions, external context etc.--Andrew HeatherAndrew Heatherhttps://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/503sampledSets - enable writer construction from dictionary; glTF export2021-12-06T13:14:10ZAndrew HeathersampledSets - enable writer construction from dictionary; glTF export## sampledSets - added writer construction from dictionary
The `sampledSets` `writer` is now constructed with a dictionary to enable custom options using a new `formatOptions` dictionary - see example below.
## glTF format
glTF is a c...## sampledSets - added writer construction from dictionary
The `sampledSets` `writer` is now constructed with a dictionary to enable custom options using a new `formatOptions` dictionary - see example below.
## glTF format
glTF is a common data exchange format for virtual reality software, e.g. [ESI's IC.IDO](https://www.esi-group.com/products/virtual-reality). Scenes are described using a JSON representation and the field/binary data is stored in an external file.
These changes add [glTF v2](https://www.khronos.org/registry/glTF/) as an option when writing `sampledSets` and particle tracks.
Note: glTF files can also be read in ParaView v5.9
### Additions:
- The `particleTracks` utility:
- output path has been updated to `postProcessing/lagrangian/<cloudNme>/particleTracks/`;
- has a new option to limit the number of tracks exported; and
- supports field export (previously only geometry was written).
- example:
cloud reactingCloud1;
sampleFrequency 1;
maxPositions 1000000;
//maxTracks 5; // optional limit on the number of tracks
setFormat <format>;
// Optional field specification; wildcards supported
// - if ommitted all fields are written
fields (d T);
- glTF format support added to sampledSets, e.g.
type sets;
libs (sampling);
interpolationScheme cellPointFace;
setFormat gltf;
### glTF format options
Controls are exposed via the `formatOptions` dictionary, e.g.
setFormat gltf;
formatOptions
{
...
}
Options include:
- Adding colour (RGBA):
formatOptions
{
colour yes;
}
By default, this will add colour fields named `COLOR_0`, `COLOR_1`, ... `COLOR_N` corresponding to each value field, using the default colour map (coolToWarm), anchoring the colour map limits to the field minimum and maximum.
Individual field specification is enabled using a `fieldInfo` sub-dictionary, e.g.
formatOptions
{
colour yes;
fieldInfo
{
T // Field name
{
// Optional colour map; default = coolToWarm
colourMap fire;
// Alpha channel description
alpha field; // uniform | field;
//alphaValue 0.1; // uniform alpha value
alphaField T;
normalise yes;
}
}
}
Note that when using the `field` option for alpha channel scaling, the selected field should be the same type as the field being output, i.e. scalar, vector etc. since the fields are grouped into their primitive types when output.
![Screenshot_from_2021-11-26_14-40-53](/uploads/28f5fd037e102b9887a38c08d59cf5eb/Screenshot_from_2021-11-26_14-40-53.png)
Particle tracks have some additional options:
- Static tracks can be written as a set of points along the track (lines support may be added in the future). Specification is the same as above
![Screenshot_from_2021-11-26_14-40-27](/uploads/a3f687dd4ccd9d5cca5e80e830c0fdef/Screenshot_from_2021-11-26_14-40-27.png)
- Tracks can be animated, i.e. seeding a particle at the start of the track and then updating its position as a function of time:
```
formatOptions
{
animate yes;
colour yes;
animationInfo
{
colour field;
colourMap rainbow;
colourField d;
// Optional colour map min and max limits
//min 0;
//max 0.002;
//alpha uniform;
//alphaValue 1;
alpha field;
alphaField d;
normalise yes;
}
}
```
Note that the particle colour for animated tracks remains constant; dynamic colour values are not currently supported by the format.
## Examples
See:
- $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter/system/sample
- $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter/constant/particleTrackProperties
- $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter/constant/particleTrackProperties.animatev2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/504Added functionality for smoothing the sensitivity derivatives2021-12-09T09:18:37ZAndrew HeatherAdded functionality for smoothing the sensitivity derivatives### Summary
Adjoint-based sensitivity maps can now be optionally smoothed using a Laplace-Beltrami operator.
When computing sensitivity maps on surface meshes generated from industrial
geometries, the outcome might appear noisy, especi...### Summary
Adjoint-based sensitivity maps can now be optionally smoothed using a Laplace-Beltrami operator.
When computing sensitivity maps on surface meshes generated from industrial
geometries, the outcome might appear noisy, especially if a volume-to-surface
approach is used for meshing, like the one utilised by snappyHexMesh. Even
though the sensitivity map is technically correct, the noisy patterns that
appear might make the extraction of useful information challenging.
This new feature facilitates the interpretation of the sensitivity map in such cases.
### Details of new models
The sensitivity map can be smoothed using a Laplace-Beltrami operator of the form
```math
\tilde{m} - \frac{\partial}{\partial x_j}\left[R^2\frac{\partial \tilde{m}}{\partial x_j}\right] = m
```
where $`\tilde{m}`$ is the smoothed sensitivity map, $`m`$ is the original
sensitivity map and $`R`$ a smoothing radius. The latter is computed as a
multiple of the average 'length' of the boundary faces, if not provided by the
user explicitly.
The above-mentioned equation is solved on the part of the surface mesh defined
by the patches on which the sensitivity map is computed, using the finiteArea
infrastructure of OpenFOAM.
If an faMesh is provided, it will be used; otherwise it will be created on the
fly based on either an faMeshDefinition dictionary in system or one constructed
internally based on the sensitivity patches.
From an optimisation point of view, this smoothing can alternatively be seen as computing the sensitivity derivatives $`\frac{\delta J}{\delta b_i}`$ of the objective function $`J`$ w.r.t. a different set of design variables $`b_i, i\in[1,N]`$, defined as
```math
x_i = x_i^{init} + \tilde{b_i} \\
\tilde{b_i} - \frac{\partial}{\partial x_j}\left[R^2\frac{\partial \tilde{b_i}}{\partial x_j}\right] = b_i
```
where $`x_i`$ are the coordinates of the updated geometry and $`\tilde{b_i}`$ a smooth displacement field. In other words,
no loss of accuracy is incurred by the smoothing; instead, sensitivities are computed w.r.t. a different set of design variables.
### Examples
An example of a noisy sensitivity map and its smoothed variants using different $`R`$ values is presented below, taken from the updated motorbike tutorial under
$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/sensitivityMaps/motorBike,
![portFront](/uploads/c7a772e62d98ea0a34414c7cd05ffa1c/portFront.png)
![port](/uploads/ec1bb55d3255e3dd403818ec21c09245/port.png)
![top](/uploads/9ddc8a60520cedba99780974f71e422f/top.png)
### Risks
No risks are foreseen. To enable the smoothing, the `smoothSensitivities` bool should be set to `true`, along with some optional entries.
```
sensitivities
{
type surfacePoints;
patches (motorBikeGroup);
includeSurfaceArea false;
smoothSensitivities true;
meanRadiusMultiplier 10; // Optional, defaults to 10. Controls the smoothing radius
iters 2000; // Optional, defaults to 500
}
```
Since the Laplace-Beltrami equation is solved using the finiteArea framework, `faSchemes` and `faSolution` should be present under `system`.
The smoothed sensitivity map is written in the `smoothedSurfaceSens + adjointSolverName + sensitivityFormulation` file, under the current time-step.
### References
The notion of sensitivity smoothing using a Laplace-Beltrami operator was used throught the seminal works of Antony Jameson. A reference can be found in
Vassberg J. C., Jameson A. (2006). Aerodynamic Shape Optimization Part I: Theoretical Background. VKI Lecture Series, Introduction to Optimization and Multidisciplinary Design, Brussels, Belgium, 8 March, 2006.v2112Andrew HeatherAndrew Heather