openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2023-11-24T19:57:20Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/639ENH: Reduced-order modelling field reconstruction with DMD2023-11-24T19:57:20ZKutalmış BerçinENH: Reduced-order modelling field reconstruction with DMD#### Acknowledgement
OpenCFD would like to acknowledge and thank **Marco Kiewat** for his contributions, elaborate suggestions and help, and critical recommendations. Highly appreciated.
#### Problem
- OpenFOAM currently lacks one of ...#### Acknowledgement
OpenCFD would like to acknowledge and thank **Marco Kiewat** for his contributions, elaborate suggestions and help, and critical recommendations. Highly appreciated.
#### Problem
- OpenFOAM currently lacks one of the key advantages of DMD:
- the capability to generate a field based on given modes and their associated dynamics, without the need for any CFD computations at arbitrary intermediate and/or future time points.
- This functionality would allow users to condense an entire simulation into a few modes and mode dynamics, and subsequently generate fields at any desired time or predict their future states of periodic or pseudo-periodic systems, all without the need for additional CFD analyses.
#### Solution
Implement and verify the method proposed by [Kiewat (2019)](https://mediatum.ub.tum.de/doc/1482652/815436.pdf) to generate time-variant field data from DMD data for a set of specified times.
#### Verification
##### Coarse mesh
![image](/uploads/a00f43670020abb4737a0e37306ea550/image.png)
![coarse](/uploads/000bb2117e883f9ca7cfebeb2c3b7f2c/coarse.mp4)
##### Fine mesh
![image](/uploads/d3e5ba304c0997de719d6eb07dee918b/image.png)
![fine](/uploads/6d1d980ba1a1eb42ba8a8cc79d8d0396/fine.mp4)
#### Discussion
- The quality of results depends on the capabilities of the underlying reduced-order model, and the quality of the input data.
- To improve the reconstruction results, one needs to make sure that modes are correctly extracted from the flow.
- The easiest method to check the quality:
- Inspect the real part of the first mode visually.
- Compare it with the time-mean of the operand decomposed field.
- The real part of the first mode should always look like the time-mean of the operand decomposed field.
- If both fields are dissimilar, expect low quality results from the `createROMfields`.
#### Risks
- No change in existing input/output.
- The tutorial `$FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/cylinder2D` is run for a longer period.
- Also, the parallel `renumberMesh` operation is removed from its existing `Allrun` script.
#### Metadata
- [x] linux64ClangDPInt32Opt (clang15)
- [x] linux64GccDPInt32Opt
- [x] linux64GccSPDPInt64Debug
- [x] Alltest: No new error/No change in existing output
- [x] Test cases: `$FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/cylinder2D`v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/561ENH: faceZoneReferenceTemperature: new heatTransferCoeff model2022-11-21T15:59:47ZKutalmış BerçinENH: faceZoneReferenceTemperature: new heatTransferCoeff modelEP1947 - see `faceZoneReferenceTemperature.H` for model usage.EP1947 - see `faceZoneReferenceTemperature.H` for model usage.v2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/560Integration of grey area turbulence models from Upstream CFD2022-11-07T11:33:34ZAndrew HeatherIntegration of grey area turbulence models from Upstream CFD## Summary
- Refactoring of Spalart-Allmaras (SA) models
- New class hierarchy to reduce code duplication
- Trip term (ft2) now on a user switch
- Was previously active, now deactivated by default
- Enhancements to DES models...## Summary
- Refactoring of Spalart-Allmaras (SA) models
- New class hierarchy to reduce code duplication
- Trip term (ft2) now on a user switch
- Was previously active, now deactivated by default
- Enhancements to DES models to include grey area model effects in collaboration with @MarianFuchs, Upstream CFD GmbH
- sigma extension for SA and k-omega DES, DDES models
- New LES delta functions
- `DeltaOmegaTilde`
- `SLADelta`
- New sigma LES model
- Extended `turbulenceFields` function object
- Added writing of DES shielding function (fd) and LES region indicator fields
- Added warnings for DES model usage; DDES forms should be employed instead
## Details of new models (If applicable)
### Grey area turbulence
The new sigma treatment is available for the models:
- `SpalartAllmarasDES`, `SpalartAllmarasDDES`, `SpalartAllmarasIDDES`
- `kOmegaSSTDES`, `kOmegaSSTDDES`, `kOmegaSSTIDDES`
and activated via the `useSigma` switch, e.g.
```
simulationType LES;
LES
{
LESModel SpalartAllmarasDDES;
SpalartAllmarasDDESCoeffs
{
useSigma true; // <-- new entry
}
//delta SLADelta; // DeltaOmegaTilde;
delta DeltaOmegaTilde;
DeltaOmegaTildeCoeffs
{}
...
}
```
Test case: [wallMountedHump.tgz](/uploads/cea302870310f2b2bf17dc81ff1fbcae/wallMountedHump.tgz) provided by @MarianFuchs
References:
- Mockett, C. et al. (2015). Two Non-zonal Approaches to Accelerate RANS to LES Transition of Free Shear Layers in DES. In: Girimaji, S., Haase, W., Peng, SH., Schwamborn, D. (eds) Progress in Hybrid RANS-LES Modelling. Notes on Numerical Fluid Mechanics and Multidisciplinary Design, vol 130. Springer, Cham. https://doi.org/10.1007/978-3-319-15141-0_15
- Fuchs, M. et al. (2016). Further Assessment of the Grey-Area Enhanced σ-DES Approach for Complex Flows. ERCOFTAC Bulletin 108
- Fuchs, M. et al. (2015). Assessment of novel DES approach with enhanced SGS modelling for prediction of separated flow over a delta wing. AIAA 2015-3433. https://doi.org/10.2514/6.2015-3433
### Extended turbulenceFields function object
The `turbulenceFields` function object now included writing for:
- `fd` : DES shielding function
- `LESRegion` : LES indicator field
An example usage has been added to the `$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/vortexShed` case:
```
functions
{
turbulenceFields1
{
type turbulenceFields;
libs (fieldFunctionObjects);
writeControl writeTime;
fields (fd LESRegion);
}
...
```
### Risks
- Possible regressions in SA models following code refactoringv2212Kutalmış BerçinKutalmış Berçinhttps://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/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/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/532ENH: turbulentDigitalFilter: Synthetic fluctuations of scalars2022-06-07T20:12:35ZKutalmış BerçinENH: turbulentDigitalFilter: Synthetic fluctuations of scalars**Aim**
To enable synthetic fluctuations of scalars (e.g. temperature or contaminant concentrations) for the `turbulentDigitalFilterInlet` boundary condition.
**Previous status**
- Produces only vector-based fluctuations
- Input en...**Aim**
To enable synthetic fluctuations of scalars (e.g. temperature or contaminant concentrations) for the `turbulentDigitalFilterInlet` boundary condition.
**Previous status**
- Produces only vector-based fluctuations
- Input entries of mean and Reynolds stresses are limited to be either constant or simple wall-normal profiles
- Contains unresolved bugs:
- #1725
- #2262
- #2267 (Parallelisation)
- #2329 (FSM is inoperative)
- Domain rotations/translations are not possible
- Parallelisation and scaling are problematic
- Restart is problematic
- Mapping fluctuations onto an inlet patch is problematic and limited to only the nearest-cell option
- Adjustable time-step simulations are not possible
**Improvements**
- Produces vector- or scalar-based fluctuations
- New input-entry types:
- Mean and Reynolds stresses have become `PatchFunction1` type
- Time-variant input for mean and Reynolds stresses is possible
- Number of input entries have been simplified by reducing the number from 16 to 8, most of which are default valued.
- Resolves the reported bugs
- Domain rotations/translations are improved
- Users can set a local coordinate system
- Parallelisation and scaling are improved
- Restart is improved
- Mapping fluctuations onto an inlet patch is improved and generalised
- Users can select an AMI mapping method for the mapping operation
- Adjustable time-step simulations are possible for the FSM option
- Removes Taylor's frozen turbulence assumption for the streamwise integral scale calculations
**Resolved bugs**
#1725 #2262 #2267 #2329
**Methodology**
<img src="/uploads/ed664afc764a1894db265b8210796b0d/image.png" width="50%" height="50%">
<img src="/uploads/4fc57b37db8180bb261c3d808bd14ff8/image.png" width="50%" height="50%">
#### Results
**DFM - only vector**
<img src="/uploads/b8b00f5758bc3998f81fb80908c121b6/image.png" width="85%" height="85%">
**DFM - only scalar**
<img src="/uploads/10ab195728e01971af04b14e01a109fc/image.png" width="85%" height="85%">
**DFM - vector+scalar**
<img src="/uploads/b1a26f36c48a1d63c1c09d17b2d6f7a3/image.png" width="85%" height="85%">
**FSM - only vector**
<img src="/uploads/58877dd2e728e8e91fe8f188356c09ef/image.png" width="85%" height="85%">
**FSM - only scalar**
<img src="/uploads/422232e58ae5ddcf60ce7d47877e3262/image.png" width="85%" height="85%">
**FSM - vector+scalar**
<img src="/uploads/f159b9a384b792912bf2d5c89b76c4f0/image.png" width="85%" height="85%">
### Meta-data
EP#1730
* [x] Clean compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error
### Future work - Constraints
- Test scope should be extended further for:
- Integral length scales
- Domain rotations and/or translations
- Multiphase-flow cases
- Dynamic-mesh cases
- Overset meshes
- Mesh (un)refinements
- Collated-data format
- Hybrid and single precisions
- `transformPoints` utility has no effect on `boundaryData` input, which can slow down case preparations for input sets which need to be rotated/translated
- Scalar-based condition
- No constraints on nonpositive output
- Scarce and ambiguous academic resources
- No cross-correlations
- Not easy to produce/find benchmark data from theory or measurements
- Usefulness is not clarified by academia
- DFM
- Incomplete parallelisation of the three-dimensional separable convolution due to the lack of no open-source algorithms
- ~~The use of `redistributePar -decompose` utility is not supported.~~v2206Andrew HeatherAndrew Heatherhttps://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/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/505ENH: Adding dynamic-mesh motion capabilities to various solvers2021-12-16T09:05:01ZKutalmış BerçinENH: Adding dynamic-mesh motion capabilities to various solvers### Summary
With the commit, the `dynamicMeshMotion` functionalities and the following solvers can operate in combination.
- `buoyantBoussinesqPimpleFoam`
- `buoyantPimpleFoam`
- `rhoCentralFoam`
- `rhoCentralDyMFoam` has been merged...### Summary
With the commit, the `dynamicMeshMotion` functionalities and the following solvers can operate in combination.
- `buoyantBoussinesqPimpleFoam`
- `buoyantPimpleFoam`
- `rhoCentralFoam`
- `rhoCentralDyMFoam` has been merged with `rhoCentralFoam`
### Resolved bugs
N/A
### Risks
- No changes in user input.
- No changes in any output of the existing tutorials except those for `rhoCentralFoam`.
### Tests
* 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/521Lagrangian modelling updates/new features2021-12-15T10:46:58ZAndrew HeatherLagrangian modelling updates/new featuresMultiple enhancements:
- `PatchInjectionModel`: updated to include additional velocity specification options
- `ConeNozzleInjection`: updated to enable dynamic position and direction vectors
- `FaceInteraction`: new `cloudFunctionObject...Multiple enhancements:
- `PatchInjectionModel`: updated to include additional velocity specification options
- `ConeNozzleInjection`: updated to enable dynamic position and direction vectors
- `FaceInteraction`: new `cloudFunctionObject`
## PatchInjectionModel
The parcel initial velocity can now be set using the new `velocityType`
entry, taking one of the following options:
- `fixedValue` : (default) same as earlier versions, requires `U0`
- `patchValue` : velocity set to seed patch face value
- `zeroGradient` : velocity set to seed patch face adjacent cell value
Example usage:
```
model1
{
type patchInjection;
massTotal 1;
SOI 0;
parcelBasisType mass;
patch cylinder;
duration 10;
parcelsPerSecond 100;
velocityType patchValue;
//velocityType zeroGradient;
//U0 (-10 0 0);
flowRateProfile constant 1;
sizeDistribution
{
type normal;
normalDistribution
{
expectation 1e-3;
variance 1e-4;
minValue 1e-5;
maxValue 2e-3;
}
}
}
```
See the new $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/spinningDisk tutorial
## ConeNozzleInjection
- Now only has the options `point` and `disk` (deprecated `movingPoint`)
- moving state is based on the type of `Function1`
- The position and direction entries are `Function1`-types, e.g. for the `table` type the entries could be:
```
position table
(
( 0 (0.1 0.5 0.5))
(0.2 (0.5 0.9 0.5))
(0.4 (0.9 0.5 0.5))
(0.6 (0.5 0.1 0.5))
(0.8 (0.5 0.5 0.9))
(1.0 (0.5 0.9 0.5))
(1.2 (0.5 0.5 0.1))
(1.4 (0.5 0.1 0.5))
);
direction table
(
( 0 ( 1 0 0))
(0.2 ( 0 -1 0))
(0.4 (-1 0 0))
(0.6 ( 0 1 0))
(0.8 ( 0 0 -1))
(1.0 ( 0 -1 0))
(1.2 ( 0 0 1))
(1.4 ( 0 1 0))
);
```
## FaceInteraction
Enables particles to interact with mesh faces (described using `faceZones`).
```
faceInteraction1
{
type faceInteraction;
faceZones
(
(blockageFaces stick)
// (blockageFaces escape)
// (blockageFaces rebound) // not applicable for this test case (!)
);
dMin 0;
dMax 1;
}
The `faceZones` entry is a list of (`faceZoneName` `interactionType`), where interaction type is either `stick`, `escape` or `rebound`.
No tutorial added yet; for testing: reactingParcelFoam case: [filter.tgz](/uploads/e0034538f6c9bb85c0cfa3e1068a6ba2/filter.tgz)v2112https://develop.openfoam.com/Development/openfoam/-/merge_requests/520ENH: rigidBodyMotion: new Function1-type accelerationRelaxation2021-12-15T10:17:12ZKutalmış BerçinENH: rigidBodyMotion: new Function1-type accelerationRelaxationTUT: floatingObject: add Function1-type accelerationRelaxation exampleTUT: floatingObject: add Function1-type accelerationRelaxation examplev2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/512INT: age/comfort: New field function objects2021-12-13T17:07:01ZKutalmış BerçinINT: age/comfort: New field function objects(Explanatory content by @THO - I just added/removed few things)
### Summary
#### Function object: age
This functionObject calculates the so called `age of air` inside any domain. This is useful in HVAC analysis to check the ventilation...(Explanatory content by @THO - I just added/removed few things)
### Summary
#### Function object: age
This functionObject calculates the so called `age of air` inside any domain. This is useful in HVAC analysis to check the ventilation of a room, office, theater, cinema, academic rooms etc.
The function object is similar to use the `scalarTransport` function object + adding a source term via `fvOptions`. However, the main advantage of the `age` functionObject is that the user does not have to provide the `volScalarField`. It is generated automatically based on the patches a user uses:
- All patches of type patch (mainly used for inlet/outlets in HVAC) does get an `inletOutlet` boundary type while the `inletValue` is set to 0 (fresh air)
- All other patches of any other type, e.g., walls, are set to `zeroGradient`
- The `volScalarField` is generated during the execute routine - could be improved by checking if it is in the registry already, if yes take it otherwise create it
- For each time-step the steady-state solution of the age is calculated, and therefore the user can control the convergence:
- by setting the `tolerance` for the initial residual
- `nCorrs` for how many corrector loops are executed
- If either the `nCorrs` or the `tolerance` is reached, the loop is left and the field is stored
#### Function object: comfort
This functionObject calculated values based on the `ISO EN 7730:2005` for human behavior inside rooms. This is mainly used in HVAC analysis. The functionObject calculated (until now) three quantities:
PPD - predicted percentag of dissatisfaction
PMV - predicted mean vote
DR - draught rate
The calculations of PPD, PMV, and DR are normally single values for a single room: so its just rough guess. With CFD we have the possibility to evaluate each numerical cell separately and hence, HVAC analysis can predict more accurate and more understandable results. HVAC analysis also used for swimming bath, sauna areas and much more.
These quantities are based on the following computed fields:
Temperature
Velocity
Turbulent kinetic energy (if available)
Optional input parameters:
Clothing factor (what people wear - data are given in ISO EN 7730)
Methabolic rate
externalWork (commonly 0)
radiation temperature, if not given calculated based on surface-temperatures
relative humidity
saturation pressure, if not given will be calculated in the function object otherwise
tolerance (for the loop in a sub-function to calculate the clothing temperature)
maxClothIter (number of iterations to calculate the clothing temperature)
meanVelocity; either use the local cell velocity field for each
### Resolved bugs
N/A
### Details of new models
#### Function object: age
* Based on laboratory experiments:
```
Bartak, M., Cermak, M., Clarke, J.A., Denev, J.,
Drkal, F., Lain, M., Macdonald, I.A., Majer, M., Stankov, P., 2001.
Experimental and numerical study of local mean age of air.
In: Proceedings of the 7th International Building Performance
Simulation Association (IBPSA) Conference, Rio de Janeiro, Brazil.
Bartak, M., Beausoleil-Morrison, I., Clarke, J.A., Denev, J., Drkal, F.,
Lain, M., Macdonald, I.A., Melikov, A., Popiolek, Z., Stankov, P., 2002.
Integrating CFD and building simulation. Building and Environment 37, 865–871.
```
* A laboratory experiment of a test room with mixing ventilation, where the measurements were taken by a tracer-gas concentration-decay method.
* "At first a uniform tracer-gas distribution in the test room was reached, then the tracer-gas marking was cut off and the decay of the tracer-gas concentration due to the fresh (non-marked) ventilating air was measured."
![image](/uploads/cf5f1628cedd6258f2f37c20ff8b6ca2/image.png)
![image](/uploads/0e09e4056eca0fbf58582e17ebc4725b/image.png)
#### Function object: comfort
Unluckily, there is no validation case available for this function object. The only possible "check" is to use a one-cell domain, set parameters (as given in the EN ISO 7730:2005) and check if the same results are outputted.
### Risks
- No changes in user input
- No changes in existing outputv2112Andrew 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/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/496ENH: New suite for electrostatic deposition applications2021-11-24T18:06:40ZKutalmış BerçinENH: New suite for electrostatic deposition applications### Summary
- New suite for electrostatic deposition applications
- Solver function object: `electricPotential`: Computes the steady-state equation of charge conservation to obtain the electric potential by strictly assuming a quasi-...### Summary
- New suite for electrostatic deposition applications
- Solver function object: `electricPotential`: Computes the steady-state equation of charge conservation to obtain the electric potential by strictly assuming a quasi-static electrostatic field for single-phase and multiphase applications.
- Finite-volume boundary condition: `electrostaticDeposition`: A boundary condition to calculate electric potential (`V`) on a given boundary based on film thickness (`h`) and film resistance (`R`) fields which are updated based on a given patch-normal current density field (`jn`), Coulombic efficiency and film resistivity.
- Allowing to set:
- Minimum current density for deposition onset
- Minimum accumulative specific charge for deposition onset
- Resistance due to main body and/or pretreatment layers
- Initial electric potential
### Resolved bugs
N/A
### Details of new models (If applicable)
A showcase illustrating the verification of the `electricPotential` function object. Right: dielectric-dielectric water-air; left: conductive-dielectric water-air mixture ([López-Herrera et al., 2011](https://www.doi.org/10.1016/j.jcp.2010.11.042)).
![image](/uploads/fd8508ee81de44186bcc26d60eebc0f3/image.png)
A showcase illustrating the `electrostaticDeposition` BC: pending
### Risks
- No changes in existing output.
### Constraints
- Depletion or abrasion of material due to negative current is not allowed.
- Boundary-condition updates are not allowed during outer corrections to prevent spurious accumulation of film thickness.
- `resistivity`, `jMin`, `qMin` and `Rbody` are always non-negative.
- Quasi steady
- No electrolyte/ionic transport
- Quiescent
- Sufficiently mixed
- No magnetic field
- No electrolyte and electric field interaction
- Isotropic material and electrolyte
- No film-flow interactions
- No finite-area numerics
### Remaining issues
- Micro/nano current densities/potential differences cause numerical instabilities.
- Small diffs in patch-normal current-density values of cathode faces can lead to small diffs in incremental film thickness (Delta_h) on those faces. With the very high value of 'resistivity', the small diffs in 'Delta_h' can then lead to comparable diffs in incremental electric potential differences across patch faces.
- These differences can then be accumulated throughout a simulation, causing non-zero potential difference gradients across faces of the cathode.
- Our workaround was to round the floating-point numbers of operand variables to a given number of decimal points (default: 8 decimals) - disallow micro/nano volts, so that such accumulation could be avoided.
- However, this issue may cause numerical instabilities in more complex cases.
- Therefore, the original expressions of the formulation may need to be revisited.
- Advanced electrodeposition applications using OpenFOAM can be visited as well:
- [Kauffman et al., 2020](https://doi.org/10.3390/fluids5040240)
- [López-Herrera et al., 2011](https://www.doi.org/10.1016/j.jcp.2010.11.042)
- [Roghair et al., 2013](https://ris.utwente.nl/ws/portalfiles/portal/5676495/Roghair+Paper_final_draft_v1.pdf)
- Takayama et al., 2013, Implementation of a Model for Electroplating in
OpenFOAM.
- [Kashir et al., 2019](https://www.doi.org/10.1063/1.5050793)
- [EHDIonFOAM](https://openfoamwiki.net/index.php/Extend-bazaar/solvers/multiphase/EHDIonFOAM)v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/493ENH: new RANS model for geophysical applications2021-11-08T18:58:08ZKutalmış BerçinENH: new RANS model for geophysical applications### Summary
- ENH: kL: new RANS model for geophysical applications
- STYLE: atmosphericModels: regroup atmospheric turbulence models
- ENH: kEpsilonLopesdaCosta: enable this RANS model for compressible applications
- TUT: atmFlatTer...### Summary
- ENH: kL: new RANS model for geophysical applications
- STYLE: atmosphericModels: regroup atmospheric turbulence models
- ENH: kEpsilonLopesdaCosta: enable this RANS model for compressible applications
- TUT: atmFlatTerrain: add an example for kL RANS model
- BUG: atmFlatTerrain: fix input settings in the plot script
### Resolved bugs (If applicable)
- A small issue in `atmFlatTerrain/precursor/plot` has been corrected.
### Details of new models (If applicable)
- For a given case, the `kL` model reduces numerical costs approximately by one-third in comparison to the `kEpsilon` model for geophysical applications.
- A set of results obtained from the `atmFlatTerrain` and `atmForestStability` tutorials (left: kEpsilon, right: kL):
![image](/uploads/79d0f1db91983844da41db3af79599b6/image.png)
![image](/uploads/e1190ba19b50ddc5a093660d7f2ee4cd/image.png)
![image](/uploads/d6999f8f9d833e90acaf0a941a428c1d/image.png)
![image](/uploads/c8fbc676998046df8f8498e935ba1f21/image.png)
![image](/uploads/03df4d3859b04af634bb2c05d7391080/image.png)
![image](/uploads/d6c34c1c9e2144096b73363e8f12297c/image.png)
### Risks
- No changes in user input.
- No changes are expected in output.
- The directory structure of `src/atmosphericModels` has been changed. Therefore, the location of the directory `kEpsilonLopesdaCosta` has also been changed. Might affect few minor things for a few developers. Not crucial, IMHO.
### Tests
* [x] Compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No change in output with respect to the develop HEAD + no errorv2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/476ENH: turbulenceFields: various improvements2021-08-04T11:37:18ZKutalmış BerçinENH: turbulenceFields: various improvements- 55f61a0037 - ENH: turbulenceFields: enable custom prefix for output fields
- 8f16527a51 - BUG: turbulenceFields: unset duplicate already-registered fields
- 86f753b7bc - DOC: turbulenceFields: improve header documentation
- 189053421c...- 55f61a0037 - ENH: turbulenceFields: enable custom prefix for output fields
- 8f16527a51 - BUG: turbulenceFields: unset duplicate already-registered fields
- 86f753b7bc - DOC: turbulenceFields: improve header documentation
- 189053421c - STYLE: turbulenceFields: apply more recent OpenFOAM-coding practices
- 4243291c52 - BUG: turbulenceFields: use omega funcs of turbulence models (fixes #2132)
#### Resolved bugs
#2132
#### Test cases
[steadyBoundaryLayer](https://tinyurl.com/5fbtx82v)v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/463ENH: Adding subMesh option to momentumError and div FOs2021-07-03T19:59:35ZSergio FerrarisENH: Adding subMesh option to momentumError and div FOs- Adding subMesh capabilities to momentumError and div FOs.
- A subMesh is created from cellZones to compute FOs.
- The operators (div, etc) are only calculated in the subMesh.
- Zero field is written in the non-subMesh cells.
- Op...- Adding subMesh capabilities to momentumError and div FOs.
- A subMesh is created from cellZones to compute FOs.
- The operators (div, etc) are only calculated in the subMesh.
- Zero field is written in the non-subMesh cells.
- Optionally, halo cells can be added to the cellZones.
- New helper class to handle the subMesh creation and field mapping.
- TUT: add an example to `tutorials/compressible/rhoSimpleFoam/aerofoilNACA0012`v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/473TUT: multiphase: replace boatAndPropeller with rigidBodyHull2021-06-22T22:42:07ZKutalmış BerçinTUT: multiphase: replace boatAndPropeller with rigidBodyHull`Alltest` & `Allrun` good.`Alltest` & `Allrun` good.v2106Sergio FerrarisSergio Ferraris