openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2022-06-08T12:59:50Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/546ENH: new tabulated anisotropic solid transport model2022-06-08T12:59:50ZKutalmış BerçinENH: new tabulated anisotropic solid transport modelEP1878
#### Summary
This feature allows users to specify tabulated anisotropic thermal conductivity
properties for solid thermodynamics with an optional coordinate system specification.
The transport model is called `tabulatedAnIso`, ...EP1878
#### Summary
This feature allows users to specify tabulated anisotropic thermal conductivity
properties for solid thermodynamics with an optional coordinate system specification.
The transport model is called `tabulatedAnIso`, and as an example, the model
is specified in `thermophysicalProperties` file as follows:
```
thermoType
{
type heSolidThermo;
mixture pureMixture;
transport tabulatedAnIso;
thermo hTabulated;
equationOfState icoPolynomial;
specie specie;
energy sensibleEnthalpy;
}
mixture
{
specie
{
molWeight 50;
}
transport
{
kappa table
(
// T kappa
( 200 (80 80 80) )
( 400 (80 80 80) )
);
// kappa <Function1<scalar>>;
}
thermodynamics
{
Hf 0;
Cp
(
( 200 450)
( 400 450)
);
Sf 0;
}
equationOfState
{
rhoCoeffs<8> (8000 0 0 0 0 0 0 0);
}
}
coordinateSystem
{
type cylindrical;
origin (0 0 0);
rotation
{
type cylindrical;
axis (1 0 0);
}
}
```
#### Tests
- [x] `linux64ClangDPInt32Opt`
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] Alltestv2206Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/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/425ENH: new solvers: overPhaseChangeInterFoam and overCompressibleInterDyMFoam2021-03-24T13:15:23ZSergio FerrarisENH: new solvers: overPhaseChangeInterFoam and overCompressibleInterDyMFoamKutalmış BerçinKutalmış Berçinhttps://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/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/578ENH: new objective functions for adjoint-based optimisation2022-12-23T15:26:02ZVaggelis PapoutsisENH: new objective functions for adjoint-based optimisation### Summary
Added five new objective functions for use in adjoint-based optimisation.
### Details of new models
The new objective functions mainly target internal flow optimisation problems. A short description and an indicative exam...### Summary
Added five new objective functions for use in adjoint-based optimisation.
### Details of new models
The new objective functions mainly target internal flow optimisation problems. A short description and an indicative example for each of them follows. All figures that follow depict the velocity magnitude.
**flowRate**
Computes and minimizes/maximizes the volume-flow rate through a given set of patches. An indicative application follows, in which the flow-rate though the upper part of the duct should be maximized (flow from left to right).
| _Initial geometry (52.8% of the flow-rate goes through the upper part)_ | _Optimised geometry (53.7% of the flow-rate goes through the upper part)_ |
| ------ | ------ |
| ![flowRate.0000](/uploads/765e7369a8ced43451e8ab29656a4c7e/flowRate.0000.png) | ![flowRate.0004](/uploads/e9aa8c5f8aec559742e622ca04e4bbc6/flowRate.0004.png) |
Tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/fork-uneven/flowRate
Source code: $FOAM_SRC/optimisation/adjointOptimisation/adjoint/objectives/incompressible/objectiveFlowRate
**flowRatePartition**
Used to distribute the inlet flow-rate to outlet patches with prescribed target percentages. An indicative application follows, in which the equal distribution of the inlet flow-rate to the two outlets is targeted.
| _Initial geometry (52.8%/47.2% distribution between the upper/lower outlets)_ | _Optimised geometry (equally distributed flow)_ |
| ------ | ------ |
| ![flowRate.0000](/uploads/765e7369a8ced43451e8ab29656a4c7e/flowRate.0000.png) | ![flowRatePartition.0009](/uploads/d631dc909a26f2bf22ff96ac06f59145/flowRatePartition.0009.png) |
Tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/fork-uneven/flowRatePartition
Source code: $FOAM_SRC/optimisation/adjointOptimisation/adjoint/objectives/incompressible/objectiveFlowRatePartition
**uniformityPatch**
Enhances the flow uniformity by minimizing the velocity variance computed on prescribed (outlet) patches (the lower outlet patch in this case).
| _Initial geometry_ | _Optimised geometry (velocity variance reduced by 34%)_ |
| ------ | ------ |
| ![flowRate.0000](/uploads/765e7369a8ced43451e8ab29656a4c7e/flowRate.0000.png) | ![uniformityPatchGeom.0004](/uploads/05507242bca1a0ea8b40d0aaa6f8dc7d/uniformityPatchGeom.0004.png)|
Tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/fork-uneven/uniformityPatch
Source code: $FOAM_SRC/optimisation/adjointOptimisation/adjoint/objectives/incompressible/objectiveUniformityPatch
**uniformityCellZone**
Enhances the flow uniformity by minimizing the velocity variance within prescribed cellZones.
In this case, the boundaries of the target cellZone are highlighted in black.
| _Initial geometry_ | _Optimised geometry (velocity variance reduced by 34%)_ |
| ------ | ------ |
| ![uniformityCellZone.0001](/uploads/a8bc0863c192f7e57ced2cc26a658885/uniformityCellZone.0001.png) |![uniformityCellZone.0010](/uploads/d3e6f8ee6bb6114e1dbaa381a6eef70f/uniformityCellZone.0010.png) |
Tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/sbend/laminar/opt/unconstrained/uniformityCellZone
Source code: $FOAM_SRC/optimisation/adjointOptimisation/adjoint/objectives/incompressible/objectiveUniformityCellZone
**powerDissipation**
Computes and minimizes the fluid power dissipation that takes place within given cellZones. If the cellZone covers the entire flow domain, this objective is equivalent to volume flow-rate weighted total pressure losses (i.e. the `PtLosses` objective function).
The boundaries of the target cellZone are highlighted in black.
| _Initial geometry_ | _Optimised geometry (Power dissipation reduced by 57% within the cellZone)_ |
| ------ | ------ |
| ![powerDissipation-partial.0001](/uploads/7e1d9b473bd08e06a7131a953bc9c1fc/powerDissipation-partial.0001.png) | ![powerDissipation-partial.0009](/uploads/ede4871e1ae40c46bf0509e15fe0b47e/powerDissipation-partial.0009.png) |
Tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/sbend/turbulent/SA/opt/powerDissipation
Source code: $FOAM_SRC/optimisation/adjointOptimisation/adjoint/objectives/incompressible/objectivePowerDissipation
Manual: [adjointOptimisationFoamManual_v2212.pdf](/uploads/7abcfe652f40106694b877e261233d70/adjointOptimisationFoamManual_v2212.pdf)v2212Andrew HeatherAndrew Heatherhttps://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/508ENH: New liquid film features2021-12-09T17:02:19ZSergio FerrarisENH: New liquid film featuresAdding addition wall-function shear stress model to the film friction at the gas interface.
Updating tutorials accordinglyAdding addition wall-function shear stress model to the film friction at the gas interface.
Updating tutorials accordinglyv2112Andrew 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/200ENH: new bitSet class and improved PackedList class (closes #751)2018-04-25T10:40:00ZMark OLESENENH: new bitSet class and improved PackedList class (closes #751)- The bitSet class replaces the old PackedBoolList class.
The redesign provides better block-wise access and reduced method
calls. This helps both in cases where the bitSet may be relatively
sparse, and in cases where advantage ...- The bitSet class replaces the old PackedBoolList class.
The redesign provides better block-wise access and reduced method
calls. This helps both in cases where the bitSet may be relatively
sparse, and in cases where advantage of contiguous operations can be
made. This makes it easier to work with a bitSet as top-level object.
In addition to the previously available count() method to determine
if a bitSet is being used, now have simpler queries:
- all() - true if all bits in the addressable range are empty
- any() - true if any bits are set at all.
- none() - true if no bits are set.
These are faster than count() and allow early termination.
The new test() method tests the value of a single bit position and
returns a bool without any ambiguity caused by the return type
(like the get() method), nor the const/non-const access (like
operator[] has). The name corresponds to what std::bitset uses.
The new find_first(), find_last(), find_next() methods provide a faster
means of searching for bits that are set.
This can be especially useful when using a bitSet to control an
conditional:
OLD (with macro):
forAll(selected, celli)
{
if (selected[celli])
{
sumVol += mesh_.cellVolumes()[celli];
}
}
NEW (with const_iterator):
for (const label celli : selected)
{
sumVol += mesh_.cellVolumes()[celli];
}
or manually
for
(
label celli = selected.find_first();
celli != -1;
celli = selected.find_next()
)
{
sumVol += mesh_.cellVolumes()[celli];
}
- When marking up contiguous parts of a bitset, an interval can be
represented more efficiently as a labelRange of start/size.
For example,
OLD:
if (isA<processorPolyPatch>(pp))
{
forAll(pp, i)
{
ignoreFaces.set(i);
}
}
NEW:
if (isA<processorPolyPatch>(pp))
{
ignoreFaces.set(pp.range());
}
v1806AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/363ENH: New atmospheric boundary layer (ABL) model suite (Part 1)2020-06-09T10:09:12ZKutalmış BerçinENH: New atmospheric boundary layer (ABL) model suite (Part 1)### Summary
This commit is the first main commit of a collaborative work between `OpenCFD Ltd.`-`ENERCON Gmbh`-`CENER`, for which there will be another comprehensive commit in the next release (may include SOWFA-6 - [see](https://gith...### Summary
This commit is the first main commit of a collaborative work between `OpenCFD Ltd.`-`ENERCON Gmbh`-`CENER`, for which there will be another comprehensive commit in the next release (may include SOWFA-6 - [see](https://github.com/NREL/SOWFA-6/issues/11) for exchange of ideas).
With this commit, OpenFOAM learns:
- How to comprehensively model (RANS) surface and Ekman atmosphere layers under (slightly/very) stable/unstable/neutral atmospheric stability conditions over spatiotemporal-variant terrain (e.g. partially forestry plain).
### Details
Please refer to the header file documentation for complete set of details.
- 8 new `fvOption`s that are usable with epsilon/omega-based RANS closure models:
- atmAmbientTurbSource
- atmBuoyancyTurbSource
- atmCoriolisUSource
- atmLengthScaleTurbSource
- atmPlantCanopyTurbSource
- atmPlantCanopyUSource
- atmPlantCanopyTSource
- atmNutSource
- 7 new `wall function`s shipped with `PatchFunction1` and `TimeFunction1` support for the input entries:
- atmAlphatkWallFunction
- atmEpsilonWallFunction
- atmNutkWallFunction
- atmNutUWallFunction
- atmNutWallFunction
- atmOmegaWallFunction
- atmTurbulentHeatFluxTemperature
- A new function object to quantify the [Obukhov length](http://glossary.ametsoc.org/wiki/Obukhov_length#:~:text=Obukhov%20length,consumption%20of%20turbulence%20kinetic%20energy.):
- ObukhovLength
- 3 new tutorials involving `buoyantBoussinesqSimpleFoam` verifications in comparison to field measurements:
- `verificationAndValidation/atmosphericFlows/atmFlatTerrain`
- verification with the `Leipzig` field experiment
- illustration of precursor/successor field mapping
- `verificationAndValidation/atmosphericFlows/atmForestStability`
- verification with the Sweden field experiment
- 2 new actuator disk modelling approaches in the existing `actuationDiskSource` wherein the incoming velocity measurements can now be held by using `topoSet`s.
### Resolved bugs (If applicable)
None.
### Verifications
The model suite was verified for `neutral stability` by the `Leipzig` experiment for which all the details can be found in, and can be reproduced by `verificationAndValidation/atmosphericFlows/atmFlatTerrain`
`buoyantBoussinesqSimpleFoam-kEpsilon`:
<img src="/uploads/96349ecee9d1561d196795b266d22cdd/u-z.png" width="250" height="500">
<img src="/uploads/146d8921d130e210f27b21f1c8a902ce/v-z.png" width="250" height="500">
`buoyantBoussinesqSimpleFoam-kOmegaSST`:
<img src="/uploads/aead7fafb086e2d918302d45660e8e61/u-z.png" width="250" height="500">
<img src="/uploads/bca10f4506b06986ed47c2114e9c43ad/v-z.png" width="250" height="500">
In addition, the model suite was verified for all spectrum of stability conditions with forestry ground by the `Sweden(?)` experiment for which all the details can be found in, and can be reproduced by `verificationAndValidation/atmosphericFlows/atmForestStability`
`buoyantBoussinesqSimpleFoam-kEpsilon` (wind speed, turbulent kinetic energy, and wind veer profiles, respectively):
<img src="/uploads/370aca91fc19f2fbb719ce4655ad4618/uNorm-zNorm.png" width="600" height="500">
<img src="/uploads/e024e77ee5460299774ccaeff9e360c5/kNorm-zNorm.png" width="600" height="500">
<img src="/uploads/d292e5901e01dbb0bc517d9c76be79b2/veer-zNorm.png" width="600" height="500">
with the Obukhov lengths:
veryStable = 44.7979
stable = 300.723
slightlyStable = 859.962
neutral = undefined
slightlyUnstable = -547.088
unstable = -265.992
`buoyantBoussinesqSimpleFoam-kOmegaSST` (wind speed, turbulent kinetic energy, and wind veer profiles, respectively):
<img src="/uploads/4e19e3e02e97044e8d2dda9e718e2e32/uNorm-zNorm.png" width="600" height="500">
<img src="/uploads/8803c8bbe63de1ac2015310615521fa2/kNorm-zNorm.png" width="600" height="500">
<img src="/uploads/c938b5ae2d5fd19e5116bd00b910809a/veer-zNorm.png" width="600" height="500">
with the Obukhov lengths:
veryStable = 67.5555
stable = 396.562
slightlyStable = 1147.69
neutral = undefined
slightlyUnstable = -707.885
unstable = -319.368
Furthermore, the persistence of atmospheric boundary layer inlet profiles downstream were quantified in comparison to the profiles near the outlet, and it was found out that the overall discrepancy is within 2%:
(wind speed, turbulent kinetic energy, turbulence intensity, and temperature horizontal profiles, respectively)
<img src="/uploads/e01e5f6429cb054adda7bddc649d4348/Horizontal_MagU.png" width="600" height="500">
<img src="/uploads/78472b8205b8c79a611793a9b0a6933a/Horizontal_k.png" width="600" height="500">
<img src="/uploads/f001568734ac5b398018ba1fd5349aa2/Horizontal_TI.png" width="600" height="500">
<img src="/uploads/21eaa5b3ec305eacb8f2af11c0226985/Horizontal_T.png" width="600" height="500">
### Risks
- **User input change:** `nutkAtmRoughWallFunction` is renamed without extra support to `atmNutkWallFunction` (ensured the bitwise regression)
- Since the majority of the utilities above are new, the potential effects on the existing utilities would only be unexpected.
v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/307ENH: New adjont shape optimisation functionality2019-12-12T14:18:22ZVaggelis PapoutsisENH: New adjont shape optimisation functionalityThe adjoint library is enhanced with new functionality enabling
automated shape optimisation loops. A parameterisation scheme based on
volumetric B-Splines is introduced, the control points of which act as
the design variables in the op...The adjoint library is enhanced with new functionality enabling
automated shape optimisation loops. A parameterisation scheme based on
volumetric B-Splines is introduced, the control points of which act as
the design variables in the optimisation loop [1, 2]. The control
points of the volumetric B-Splines boxes can be defined in either
Cartesian or cylindrical coordinates.
The entire loop (solution of the flow and adjoint equations, computation
of sensitivity derivatives, update of the design variables and mesh) is
run within adjointOptimisationFoam. A number of methods to update the
design variables are implemented, including popular Quasi-Newton methods
like BFGS and methods capable of handling constraints like SQP or constraint projection.
The software was developed by PCOpt/NTUA and FOSS GP, with contributions from
Dr. Evangelos Papoutsis-Kiachagias,
Konstantinos Gkaragounis,
Professor Kyriakos Giannakoglou,
Dr. Andy Heather
[1] E.M. Papoutsis-Kiachagias, N. Magoulas, J. Mueller, C. Othmer,
K.C. Giannakoglou: 'Noise Reduction in Car Aerodynamics using a
Surrogate Objective Function and the Continuous Adjoint Method with
Wall Functions', Computers & Fluids, 122:223-232, 2015
[2] E. M. Papoutsis-Kiachagias, V. G. Asouti, K. C. Giannakoglou,
K. Gkagkas, S. Shimokawa, E. Itakura: ‘Multi-point aerodynamic shape
optimization of cars based on continuous adjoint’, Structural and
Multidisciplinary Optimization, 59(2):675–694, 2019Andrew HeatherAndrew Heatherhttps://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/552ENH: multiFieldValue: add divide and cmptDivide operations2022-07-01T12:55:33ZKutalmış BerçinENH: multiFieldValue: add divide and cmptDivide operationsAdds two new options into `multiFieldValue` FO:
divide | Divide first entry by values
cmptDivide | Divide first entry by componentwise values
EP1898Adds two new options into `multiFieldValue` FO:
divide | Divide first entry by values
cmptDivide | Divide first entry by componentwise values
EP1898Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/406ENH: MPPIC dynamic mesh2020-12-17T21:18:00ZSergio FerrarisENH: MPPIC dynamic meshMajor changes:
- `MPPICCloud` and `MPPIC` parcel are not longer used. The `MPPIC` sub-models were added to the kinematic cloud. (files were not yet deleted)
- `MPPICDyMFoam` and `DPMDyMFoam` are updated to use the kinematic cloud.
- Aff...Major changes:
- `MPPICCloud` and `MPPIC` parcel are not longer used. The `MPPIC` sub-models were added to the kinematic cloud. (files were not yet deleted)
- `MPPICDyMFoam` and `DPMDyMFoam` are updated to use the kinematic cloud.
- Affecting tracking and general functionality :
dc4deb024b4c21bf13d7d79fb85153f9dc9cf89a (org)
c68e10378b1efc6a82cf9bf845e43aef49bb7665 (org)
2045de687433674739b8fc399bdb34d4975a3b38 (org)
9b57bc1855f073cedd47e407692a0e9beefe35dd : affects tgtPointFace srcPointFace member functions
- The rest are specific for `MPPIC`-submodels into kinematic cloud, wall interaction and AMI.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/630ENH: Moving electric sources mapped from external meshes2023-11-03T14:33:12ZKutalmış BerçinENH: Moving electric sources mapped from external meshes#### Problem
As of the current state of OpenFOAM, the following capabilities are not available:
- The ability to dynamically update cell selections in `fvOptions` through input dictionary updates.
- The absence of support in `fvOptions...#### Problem
As of the current state of OpenFOAM, the following capabilities are not available:
- The ability to dynamically update cell selections in `fvOptions` through input dictionary updates.
- The absence of support in `fvOptions` for handling moving selections, such as moving points.
- The inability to map static fields from external sources for further processing, for instance, when dealing with moving static electric-source fields within an electric field being simulated.
#### Solution
- The `cellSetOption` (hence, all `fvOptions` derived from the `cellSetOption`) received three new optional input:
- `movingPoints`: Use cells containing a given set of moving points.
- ~~`mesh`: Select cells based on a given secondary mesh.~~
- `updateSelection`: Flag to enable selection updates.
- New templated `fvOption` to constrain values of given fields with a source field from an external mesh: `<Type>MapFieldConstraint`.
- A new hook to `electricPotential` function object to accomodate internal `fvOption` constraints.
#### Verification
- (Heuristic) Test cases:[moving-electric-potential.zip](/uploads/c242520ec4e70ab52bb520446f386b24/moving-electric-potential.zip) (Prior to the review changes)
#### Risks
- No change in existing input/output.
#### Metadata
- [x] linux64ClangDPInt32Opt (clang13)
- [x] linux64GccDPInt32Opt
- [x] linux64GccSPDPInt64Debug
- [x] Alltest: No new error/No change in existing outputv2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/223ENH: momentum field function (issue #1105)2018-12-04T14:26:43ZMark OLESENENH: momentum field function (issue #1105)Calculates linear/angular momentum, reporting integral values
and optionally writing the fields.
Example
```
momentum1
{
type momentum;
libs ("libfieldFunctionObjects.so");
...
...Calculates linear/angular momentum, reporting integral values
and optionally writing the fields.
Example
```
momentum1
{
type momentum;
libs ("libfieldFunctionObjects.so");
...
selectionMode all;
writeMomentum yes;
writeVelocity no;
cylindrical true;
origin (0 0 0);
e1 (1 0 0);
e3 (0 0 1);
}
```AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/364ENH: Miscellaneous enhancement/features and bug fixes2020-06-11T12:30:36ZKutalmış BerçinENH: Miscellaneous enhancement/features and bug fixesv2006Andrew 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/659ENH: mapped: keep coupling info. Fixes #30902024-01-25T13:35:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: mapped: keep coupling info. Fixes #3090Andrew HeatherAndrew Heather