openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2021-12-09T17:02:19Zhttps://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/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/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/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/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/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/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/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/350ENH: New wall-function blending approaches2020-06-17T15:26:52ZKutalmış BerçinENH: New wall-function blending approaches### Summary
This merge request is a discussion placeholder for two topics:
- ~~Potential improvements to the wall-function hierarchies~~
- Wall-function blending treatments between viscous and inertial sublayers
##### ~~Wall-func...### Summary
This merge request is a discussion placeholder for two topics:
- ~~Potential improvements to the wall-function hierarchies~~
- Wall-function blending treatments between viscous and inertial sublayers
##### ~~Wall-function hierarchy~~
~~Arguably, the wall-function hierarchies need a reexamination as the relations have "grown organically" in the course of time. One recent problem is that `{omega,epsilon,k}Wall` functions use data members from `nutWallFunction` base class even though the former group is not derived from the latter.~~
~~One practical consequence is that `{omega,epsilon,k}Wall` always require a `nut` wall function is defined in the `nut` dictionary, otherwise simulation in question noisily fails without informing the user with useful information, e.g. [CFD-Online:Error with k-omega SST and simpleFoam (21-Feb-20)](https://www.cfd-online.com/Forums/openfoam-solving/224476-error-k-omega-sst-simplefoam.html), and the bug-fix:55776069975061c488a6294a5e81a7a92b04db45.~~
##### Wall-blending treatments
- Four wall-function blending treatments were introduced:
- `STEPWISE`
- `MAX`
- `BINOMIAL`
- `EXPONENTIAL`
- .. For the following wall functions:
- `epsilonWallFunction`
- `omegaWallFunction`
- `nut{k,U}WallFunction`
- The header-file documentations were improved for the following wall functions for which the blending treatments were not applicable (e.g. due to the continuous treatment in `nutUSpaldingWallFunction`):
- `nutU{Spalding,Tabulated,Blended}WallFunction`
- `nut{k,U}RoughWallFunction`
- `nutLowReWallFunction`
- `{kLowRe,kqR}WallFunction`
- Based on:
- Viegas and Rubesin (1983); Viegas et al. (1985) (i.e. the option: `STEPWISE`)
- Menter and Esch (2001) (i.e. the option: `BINOMIAL`)
- Popovac and Hanjalić (2007) (i.e. the options: `MAX`, `EXPONENTIAL`)
- Knopp et al. (2006) (i.e. the option: `TANH` only for `omega`)
### Resolved bugs
N/A
### Risks
High risk, yet bitwise backward compatibility, and regression were verified for each modified functionality.
@mark @Sergio @Mattijs v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/408ENH: noise models - added A, B, C, and D weightings to SPL2020-12-11T20:22:09ZAndrew HeatherENH: noise models - added A, B, C, and D weightings to SPL### Summary
Added A, B, C and D weightings to the SPL predictions and code refactoring
### Resolved bugs (If applicable)
none
### Details of new models (If applicable)
Gains:
![noiseModelWeights](/uploads/cbc1c76a7f5e3e6c9ccbbd64...### Summary
Added A, B, C and D weightings to the SPL predictions and code refactoring
### Resolved bugs (If applicable)
none
### Details of new models (If applicable)
Gains:
![noiseModelWeights](/uploads/cbc1c76a7f5e3e6c9ccbbd646e20dc53/noiseModelWeights.png)
### Risks
(Possible regressions?)
code refactoring - point and surface noise functionality needs to be confirmed
(Changes to user inputs?)
nonev2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/562ENH: noiseModels - replaced graph usage by writeFile2022-10-04T13:50:34ZAndrew HeatherENH: noiseModels - replaced graph usage by writeFileHeader information now includes, e.g.
f [Hz] vs P(f) [Pa]
Lower frequency: 2.500000e+01
Upper frequency: 5.000000e+03
Window model: Hanning
Window number: 2
Window samples: 512
Window overlap %: 5.000000e+01
...Header information now includes, e.g.
f [Hz] vs P(f) [Pa]
Lower frequency: 2.500000e+01
Upper frequency: 5.000000e+03
Window model: Hanning
Window number: 2
Window samples: 512
Window overlap %: 5.000000e+01
dBRef : 2.000000e-05
Area average: false
Area sum : 6.475194e-04
Number of faces: 473
Note: output files now have `.dat` extension
Testing: check output from
`$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/vortexShed`v2212Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/539ENH: norm: add new field function object2022-05-27T11:58:44ZKutalmış BerçinENH: norm: add new field function objectEP1871
<img src="/uploads/3a948c9898bfea03397a550370578d30/image.png" width="50%" height="50%">
<img src="/uploads/656a0375d29062e3bed28a0b6d6bb78b/image.png" width="50%" height="50%">
<img src="/uploads/99411e71d94ea8e2f98e28e8412ca7...EP1871
<img src="/uploads/3a948c9898bfea03397a550370578d30/image.png" width="50%" height="50%">
<img src="/uploads/656a0375d29062e3bed28a0b6d6bb78b/image.png" width="50%" height="50%">
<img src="/uploads/99411e71d94ea8e2f98e28e8412ca720/image.png" width="50%" height="50%">
<img src="/uploads/27a831d096d9368dffdfd06da7bf301e/image.png" width="50%" height="50%">
<img src="/uploads/49e80a7e4480b71fafdf6b115e7ef837/image.png" width="50%" height="50%">
<img src="/uploads/a215b20f7b5af40c947277050e183c5c/image.png" width="50%" height="50%">
##### Tests
- [x] `linux64ClangDPInt32Opt`
- [x] `linux64GccDPInt32Opt`
- [x] `linux64GccSPDPInt64Debug`
- [x] Alltestv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/553ENH: oscillatingLinearMotion: add optional phase- and vertical-shift entries2022-07-04T15:27:59ZKutalmış BerçinENH: oscillatingLinearMotion: add optional phase- and vertical-shift entriesThe governing equation of `oscillatingLinearMotion` for the displacement was changed to with `Function1` input entries:
```math
y = A\, sin(B (t + C)) + D
```
where:
```
y | Displacement [m] (vector)
A | Ampl...The governing equation of `oscillatingLinearMotion` for the displacement was changed to with `Function1` input entries:
```math
y = A\, sin(B (t + C)) + D
```
where:
```
y | Displacement [m] (vector)
A | Amplitude [m] (vector)
B | Radial velocity [rad/s] (scalar)
C | Phase-shift to left [s] (scalar)
D | Vertical shift [m] (vector)
```
EP1925Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/51ENH: OSspecific - softlink handling (fixes #164)2016-12-23T12:44:52ZMark OLESENENH: OSspecific - softlink handling (fixes #164)Links are followed in most cases, with some notable exceptions:
- mv, mvBak:
renames the link, not the underlying file/directory
- rmDir:
remove the symlink to a directory, does not recurse into the
underlying directoryLinks are followed in most cases, with some notable exceptions:
- mv, mvBak:
renames the link, not the underlying file/directory
- rmDir:
remove the symlink to a directory, does not recurse into the
underlying directoryAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/531ENH: outletMappedUniformInlet: add multiple fraction, offset and time delays2022-04-29T20:00:23ZKutalmış BerçinENH: outletMappedUniformInlet: add multiple fraction, offset and time delays### Summary
**Aim**
To implement a recirculation boundary
condition for an arbitrary operand scalar with:
- Multiple connected outlets and inlets
- Optional filtration fraction for each recirculation
loop
- Optional time delay for eac...### Summary
**Aim**
To implement a recirculation boundary
condition for an arbitrary operand scalar with:
- Multiple connected outlets and inlets
- Optional filtration fraction for each recirculation
loop
- Optional time delay for each recirculation loop
Additionally, write-control of `scalarTransport` was transferred from `controlDict` to the function object, and enabled `UList` parameters in `interpolateXY` for wider applications.
**Previous status**
Existing boundary condition: `outletMappedUniformInlet`
- Connected between a single outlet and a single inlet
- Instantaneous recirculation: no outlet-to-inlet time delay
- Optional filtration fraction is available as a constant value
- Optional offset is available as a constant value
**Improvements**
- Arbitrary number of outlets can be connected to a single inlet
- Each inlet can be connected to different and arbitrary
combination of outlets
- Each outlet-inlet connection has:
- Optional filtration fraction as a Function1 type
- Optional offset as a Function1 type (i.e. adding/substracting a substance)
- Optional time delay (from outlet to inlet) as a Function1 type
- Each inlet has an optional base inlet-field as a PatchFunction1 type
**Theory**
<img src="/uploads/5cd45d1e0a12a12011aa090361fa16ba/image.png" width="50%" height="50%" />
**Usage**
<img src="/uploads/d6b9aa06465e479f2fcbae6ea92f84e2/image.png" width="75%" height="75%" />
### Resolved bugs
N/A
### Methodology
**Remarks**
- Difficult to design a simple verification test case due to the amount of data
- Verifications were carried out heuristically and manually
- No validation/benchmark available
**Tests**
- Cases
- Single-outlet single-inlet, pisoFoam-LES, constant time-step: [1-single-outlet-inlet.zip](/uploads/bfe8ee7572c24cde5ccd4cb555d9b9d3/1-single-outlet-inlet.zip)
- Multiple-outlet multiple-inlet, pisoFoam-LES, constant time-step: [2-multiple-outlet-inlet.zip](/uploads/dd2b892e86e2b39f829f6189a060b23b/2-multiple-outlet-inlet.zip)
- Multiple-outlet multiple-inlet, reactingParcelFoam-RANS, adjustable time-step
- Scenarios
- Single/multiple-processor run
- Single/multiple-processor run with restart
- decomposePar
- reconstructPar
- redistributePar –decompose
-redistributePar -reconstruct
- No collated-format tests
- Only scalar fields
### Discussion
- No inlet-inlet connection
- Could not infer any necessity for an inlet-inlet
connection. Happy to be proven incorrect, however.
- No constraints were put onto the input entries;
therefore, users need to use their attention
and engineering judgements to avoid
potential unphysical results
- Except negative input of time delays are
suppresed to be zero without emitting any
warning messages.
- For example, filtration fraction can be set to
any number (e.g. more than 100%)
- Needs extensive tests to assume the
functionalities safe for any single-phase,
multiphase and overset finite-volume
applications.
### Meta-data
EP#1730
* [x] Clean compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/399ENH: outletMappedUniformInlet: add optional fraction and offset2020-12-16T18:28:32ZKutalmış BerçinENH: outletMappedUniformInlet: add optional fraction and offset### Summary
The new functionality optionally allows the patch-averaged
value to be scaled and/or offset by a pair of specified values.
Example of the boundary condition specification:
```
<patchName>
{
// Mandatory entries...### Summary
The new functionality optionally allows the patch-averaged
value to be scaled and/or offset by a pair of specified values.
Example of the boundary condition specification:
```
<patchName>
{
// Mandatory entries (unmodifiable)
type outletMappedFilterInlet;
outletPatch <outletPatchName>;
// Optional entries (unmodifiable)
fraction 0.1;
offset 10; // (1 0 0);
phi phi;
// Optional (inherited) entries
...
}
```
### Details of new models
**The tutorial `airRecirculationRoom` and related visualisations are exclusively prepared by _Alseny Diallo_**.
![Screenshot_from_2020-12-10_17-22-44](/uploads/0ca11fb914f02e7f7563d0df3e800b07/Screenshot_from_2020-12-10_17-22-44.png)
![Screenshot_from_2020-12-10_18-31-08](/uploads/10d4056dd7bdaed45d29b6e0aaddadc5/Screenshot_from_2020-12-10_18-31-08.png)
![Screenshot_from_2020-12-10_18-17-30](/uploads/83048e2a11c6ace6f8ac13cdf266fd5d/Screenshot_from_2020-12-10_18-17-30.png)
![Screenshot_from_2020-12-10_17-24-11](/uploads/cb9d2e00f334ee41f3ec8e7ff07d6902/Screenshot_from_2020-12-10_17-24-11.png)
![Screenshot_from_2020-12-10_17-24-20](/uploads/38cb29fa995ff837ed520b05c9ab37a6/Screenshot_from_2020-12-10_17-24-20.png)
![Screenshot_from_2020-12-10_17-23-19](/uploads/64a9c92d494ff19cd90e8df1a5b02bc7/Screenshot_from_2020-12-10_17-23-19.png)
![Screenshot_from_2020-12-10_18-09-54](/uploads/40806bc5b100b397998d6e5db55c3e4f/Screenshot_from_2020-12-10_18-09-54.png)
### Risks
- The bug fix may further need to be tested.
- No change to user input.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/180ENH: overset: new solvers, new stencil2017-12-14T15:43:59ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: overset: new solvers, new stencilAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/603ENH: parProfiling: profile linear solver only2023-05-03T19:04:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: parProfiling: profile linear solver only### Summary
Wrapper for linear solver to enable/disable parProfiling so it profiles only the linear solver.
### Details of new models (If applicable)
See `tutorials/IO/cavity_parProfiling`### Summary
Wrapper for linear solver to enable/disable parProfiling so it profiles only the linear solver.
### Details of new models (If applicable)
See `tutorials/IO/cavity_parProfiling`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/595ENH: ParticleHistogram: refactor PatchParticleHistogram function object2023-06-01T08:24:31ZKutalmış BerçinENH: ParticleHistogram: refactor PatchParticleHistogram function object#### Summary
- enable 'faceZone' support for the function objects below.
- introduce 'cloudFunctionObjectTools' to simplify collection of particle info
on patches or face zones.
- enable 'writeFile' support to better control file outp...#### Summary
- enable 'faceZone' support for the function objects below.
- introduce 'cloudFunctionObjectTools' to simplify collection of particle info
on patches or face zones.
- enable 'writeFile' support to better control file output.
- rename 'PatchParticleHistogram' as 'ParticleHistogram', and 'PatchPostProcessing' as 'ParticlePostProcessing' for better clarity.
#### Resolved bugs
#1808
#### Risks
- User input:
- Names of FOs have been changed
- No change in existing output.
#### Meta-data
* EP2071
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error/No change in existing outputAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/386ENH: PatchParticleHistogram: add a new cloud FO2020-11-13T09:23:26ZKutalmış BerçinENH: PatchParticleHistogram: add a new cloud FO### Summary
Computes a histogram for the distribution of particle diameters
and corresponding number of particles hitting on a given list of patches.
A minimal example by using `constant/reactingCloud1Properties.cloudFunctions`:
...### Summary
Computes a histogram for the distribution of particle diameters
and corresponding number of particles hitting on a given list of patches.
A minimal example by using `constant/reactingCloud1Properties.cloudFunctions`:
```
patchParticleHistogram1
{
// Mandatory entries (unmodifiable)
type patchParticleHistogram;
patches (<patch1> <patch2> ... <patchN>);
nBins 10;
min 0.1;
max 10.0;
maxStoredParcels 20;
}
```
### Risks
No change to user inputs / no risk to regression.
PS: approval/feedback please @mark @Sergio @Mattijs @PrashantAndrew HeatherAndrew Heather