openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2020-04-08T10:53:57Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/344ENH: improve access to the inner content of turbulence models2020-04-08T10:53:57ZKutalmış BerçinENH: improve access to the inner content of turbulence models~~WIP for `Clang` compilation test.~~ [log.linux64GccDPInt32Opt.zip](/uploads/42d7ada437728c6c6772aca28683ab81/log.linux64GccDPInt32Opt.zip) (Gcc 7.4)
[log.linux64ClangDPInt32Opt.zip](/uploads/92ba2973af16077b4f17197e0a385ae9/log.linux6...~~WIP for `Clang` compilation test.~~ [log.linux64GccDPInt32Opt.zip](/uploads/42d7ada437728c6c6772aca28683ab81/log.linux64GccDPInt32Opt.zip) (Gcc 7.4)
[log.linux64ClangDPInt32Opt.zip](/uploads/92ba2973af16077b4f17197e0a385ae9/log.linux64ClangDPInt32Opt.zip) (LLVM 9.0)
[testLoopReport.PASS.zip](/uploads/b65f5e0e1a43e1608e2ed96aee84a2cc/testLoopReport.zip)
### Summary
The commits provide access to:
- `omega` field estimations for non-omega turbulence models,
- model coefficients of turbulence models for `fvOptions`.
### Resolved bugs (If applicable)
n/a
### Details of new models (If applicable)
n/a
### Risks
- No change to the current behaviourv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/645ENH: GAMG: processor agglomeration extended for all interfaces2023-12-21T17:39:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: GAMG: processor agglomeration extended for all interfaces# Support for `cyclicAMI` in processorAgglomeration (inside GAMG)
## Problem description:
When running in parallel on many cores the coarsest level solver (e.g. `PCG`) might become the scaling bottleneck. One way to get around this is t...# Support for `cyclicAMI` in processorAgglomeration (inside GAMG)
## Problem description:
When running in parallel on many cores the coarsest level solver (e.g. `PCG`) might become the scaling bottleneck. One way to get around this is to agglomerate coarse level matrices onto less or even one processor. This is collects processors' matrices to create a single, larger matrix with all the inter-processor boundaries replaced with internal faces. This is not supported for other boundary types, e.g. cyclicAMI. When used in combination with processor agglomeration these will display an error message when serialising the boundary, e.g.
```
[2] --> FOAM FATAL ERROR:
[2] Not implemented
[2]
[2] From virtual void Foam::cyclicAMIGAMGInterface::write(Foam::Ostream&) const
[2] in file AMIInterpolation/GAMG/interfaces/cyclicAMIGAMGInterface/cyclicAMIGAMGInterface.H at line 160.
[2]
FOAM parallel run aborting
```
## Solution
The handling of boundaries was generalised to all coupled boundaries (e.g. `cyclic`, `cyclicAMI`). All will implement
- writing to / constructing from a stream (i.e. serialisation) to collect all parts of a coupled boundary on the agglomerating processor.
- cloning (on the agglomerating processor) from the received parts. For `cyclicAMI` this involves assembling the local face-to-cell addressing from the individual parts and adapting the stencils accordingly. (see below)
## Effect
A case with two 20x10x1 blocks coupled through `cyclicAMI` (decomposed into 4) was compared to a single 40x10x1 block (so using processor boundaries) using the `masterCoarsest` processor agglomeration (output from running with the `-debug-switch GAMGAgglomeration` command line option):
- processor boundaries:
```
nCells nInterfaces
Level nProcs avg max avg max
----- ------ --- --- --- ---
0 4 100 100 1.5 2
1 4 50 50 1.5 2
2 1 100 100 0 0
3 1 48 48 0 0
```
The number of boundaries ('nInterfaces') becomes 0 as all processor faces become internal.
- cyclicAMI boundaries:
```
nCells nInterfaces
Level nProcs avg max avg max
----- ------ --- --- --- ---
0 4 100 100 3 3
1 4 50 50 3 3
2 1 100 100 2 2
3 1 48 48 2 2
```
Here the number of boundaries goes from 3 to 2 since only the two `cyclicAMI` get preserved.
## Distributed cyclicAMI
A big benefit of cyclicAMI is that the source and target faces do not have to reside on the same processor. This is handled internally using a distribution map:
- `AMI.srcMap()` : transfers the source-side data to the target side.
- `AMI.tgtMap()` : transfers the target-side data to the source side.
When assembling the cyclicAMI interface from the various contributing processors a large part is the assembling of the src and tgt maps. Each map consists of local data (myProcNo) followed by data from the various remote (proci != myProcNo) procs:
|index | contents |
|-------------|-----------|
|0 | local |
|localSize | |
| | remote from 0 |
| | remote from 1 |
| | .. |
| | remote from n |
|constructSize| |
The data is constructed by
- starting from the local data
- using the `subMap` to indicate which elements of this local data need to go where
- making additional space to receive remote data
- using the `constructMap` to indicate where the received data slots into
If we start from four processors and combine the processors 0,1 into new 0 and 2,3 into new 1 the assembled layout is agglomerated:
- the local data is the agglomeration of local datas so local data on new0 is old0, old1
- the remote data is sorted according to originating 'new' processor (so new0 agglomerates the data sent to old procs 0,1 from old procs2,3)
- any remote data from assembled processors is removed (since it is now in the assembled local slots)
The two maps indexing the data will be renumbered accordingly. In general most maps will have lots of local data and just a bit of remote (note that this might not be optimal for cyclicAMI purposes since quite likely the two sides get decomposed onto separate processors) so the new numbering is
- startOfLocal[mapi] : gives for `mapi` (assumed to originate from rank `mapi`) the offset in the assembled data
- compactMaps[mapi][index] : gives the `mapi` the new index for every old index
## Notes
- `cyclicAMI` with all faces becoming local will be reset to become non-distributed i.e. directly operating on provided fields without any additional copying.
- `cyclicAMI` with a rotational transformation is not yet supported. This is not a fundamental limitation but requires additional rewriting of the stencils to take into account transformations.
- `processorCyclic` (a `cyclic` with owner and neighbour cells on different processors) is not yet supported. This is treated as a normal processor boundary so will loose any transformation. Note that `processorCyclic` can be avoided by using the `patches` constraint in decomposeParDict, e.g.
```
constraints
{
patches
{
//- Keep owner and neighbour on same processor for faces in patches
// (only makes sense for cyclic patches and cyclicAMI)
type preservePatches;
patches (cyclic);
}
}
```
- only `masterCoarsest` has been tested but the code should support any other processor-agglomeration method.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/497ENH: fvSolution: allow Function1 for all scalars2021-11-10T19:06:50ZKutalmış BerçinENH: fvSolution: allow Function1 for all scalars### Summary
- Allows the usage of `Function1` for scalar entities within `fvSolution`, e.g. for `relaxationFactors`.
### Resolved bugs
N/A
### Risks
* No changes in output.
* No changes in existing user input.
### Tests
* [x] C...### Summary
- Allows the usage of `Function1` for scalar entities within `fvSolution`, e.g. for `relaxationFactors`.
### Resolved bugs
N/A
### Risks
* No changes in output.
* No changes in existing user input.
### Tests
* [x] Compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No error
* [x] Performance testsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/557ENH: fvOptions: refactor and extend effectivenessHeatExchangerSource2022-09-07T13:55:04ZKutalmış BerçinENH: fvOptions: refactor and extend effectivenessHeatExchangerSource#### Summary
- rename effectivenessHeatExchangerSource -> heatExchangerSource
- introduce submodels:
- effectivenessTable (previous behaviour)
- referenceTemperature
- the referenceTemperature submodel uses a reference temperature
...#### Summary
- rename effectivenessHeatExchangerSource -> heatExchangerSource
- introduce submodels:
- effectivenessTable (previous behaviour)
- referenceTemperature
- the referenceTemperature submodel uses a reference temperature
which is either a scalar or calculated from a 2D interpolation
table in order to calculate the heat exchange.
- the following figure shows the verification level of
the comparisons between the original and refactored `referenceTemperature`
modules in terms of average temperature.
<img src="/uploads/40d9aad34807cfb724ecc81442327e5b/image.png" width="50%" height="50%">
#### Metadata
- EP1903
- diligently reviewed and tested by @Tobi (thanks Tobi)
- see `v2212/01-heatExchangerSource` for a test caseAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/577ENH: fvOptions: add writeFile functionality2022-12-08T11:37:58ZKutalmış BerçinENH: fvOptions: add writeFile functionalityEP2028
EP1947
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorEP2028
EP1947
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/563ENH: functionObjects: refactor and extend histogram2022-11-14T17:34:56ZKutalmış BerçinENH: functionObjects: refactor and extend histogram- new submodels:
- 'equalBinWidth': groups data into bins of equal widths (previous behaviour)
- 'unequalBinWidth': groups data into bins of unequal widths
- output files per time-step are replaced with a single output file
- silen...- new submodels:
- 'equalBinWidth': groups data into bins of equal widths (previous behaviour)
- 'unequalBinWidth': groups data into bins of unequal widths
- output files per time-step are replaced with a single output file
- silently deprecates the input entries: 'setFormat' and 'formatOptions'
#### Meta-data
* EP1969
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error/No change in existing outputv2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/24ENH: functionObjects: call execute on last time step2015-12-07T15:26:53ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: functionObjects: call execute on last time step- old convention was that on last time step it would only call end()
and not execute()
- however this meant that e.g. the functionObjectProperties file
did not get written
- and almost all functionObjects were doing an execute() insi...- old convention was that on last time step it would only call end()
and not execute()
- however this meant that e.g. the functionObjectProperties file
did not get written
- and almost all functionObjects were doing an execute() inside of end()
- new convention: call execute() on last time step, just before doing end()AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/410ENH: Function objects - added new 'multiply' function object2020-12-14T16:08:55ZAndrew HeatherENH: Function objects - added new 'multiply' function objectMultiplies a given list of (at least two or more) fields and outputs the result into a new field.
fieldResult = field1 * field2 * ... * fieldN
Minimal example by using `system/controlDict` functions:
multiply1
{
//...Multiplies a given list of (at least two or more) fields and outputs the result into a new field.
fieldResult = field1 * field2 * ... * fieldN
Minimal example by using `system/controlDict` functions:
multiply1
{
// Mandatory entries (unmodifiable)
type multiply;
libs (fieldFunctionObjects);
// Mandatory (inherited) entry (runtime modifiable)
fields (<field1> <field2> ... <fieldN>);
// Optional (inherited) entries
...
}
Serves as a precursor to a more general function object based on the `fieldExpression` toolchainv2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/246ENH: functionObject: refactored co-ordinate system usage and new forceCoeffs ...2019-06-13T14:47:10ZKutalmış BerçinENH: functionObject: refactored co-ordinate system usage and new forceCoeffs members* If applied: This commit on top of the current forceCoeffs allows the user to compute:
* Side force coefficient whose direction in curl(lift,drag),
* Yaw moment coefficient whose rotation axis in dir(lift),
* Roll moment coef...* If applied: This commit on top of the current forceCoeffs allows the user to compute:
* Side force coefficient whose direction in curl(lift,drag),
* Yaw moment coefficient whose rotation axis in dir(lift),
* Roll moment coefficient whose rotation axis in dir(drag)
* Also, for developers:
* Destructor is = default
* Some divisions were replaced by multiplications
* Some repetitive multiplications were reduced to a single oper
* Name change: momentCoeff -> pitchMomentCoeff
* Order of output is reorganised as moments(pitch,yaw,roll) and forces(lift,drag,side)
* For force coefs, the front and rear axles' contributions are computed
* Verification: Passed sanity checks and valgrind-memcheck
* What's next:
* Update for the Extended code guide entry
* Related:
* Designated pitch, yaw, roll orientation can be seen in:
en.wikipedia.org/wiki/Yaw_(rotation)#/media/File:Flight_dynamics_with_text.pngv1906AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/598ENH: forces: avoid redundant volumetric operations2023-06-06T07:29:08ZKutalmış BerçinENH: forces: avoid redundant volumetric operations#### Problem
It has been observed that employing the `forces` and `forceCoeffs` function objects in several simulations causes a slowdown ranging from 2 to 10%.
The culprits found were:
- Calculation of velocity gradient
- Redundant c...#### Problem
It has been observed that employing the `forces` and `forceCoeffs` function objects in several simulations causes a slowdown ranging from 2 to 10%.
The culprits found were:
- Calculation of velocity gradient
- Redundant calculations performed for various internal fields
#### Solution
- It is recommended to cache 'grad(U)' whenever using `forces` and `forcesCoeffs` function objects.
- The recent commits have eliminated unnecessary computations for the internal field of `devRhoReff`.
- Tests using the `simpleCar` tutorial ('grad(U)' was cached) produced the following 'profiling' figures:
![image](/uploads/c4b1c39cde976ad13cec2ee835523bf1/image.png)
- Tests using an industrial case ('grad(U)' was cached) reduced the `functionObjects.execute()` from ~72[s] to ~23[s].
#### Meta-data
* EP2065
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error/No change in existing output
* [x] No output change in all operating conditions (e.g. direct force intensity, porosity, compressible flows etc.)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/245ENH: FO: Lamb vector and its divergence2019-11-08T07:11:42ZKutalmış BerçinENH: FO: Lamb vector and its divergence- If applied:
This commit allows the user to compute:
- the Lamb vector (https://en.wikipedia.org/wiki/Lamb_vector),
- (optionally) its divergence
- on-the-fly or via postProcess utility
- for a...- If applied:
This commit allows the user to compute:
- the Lamb vector (https://en.wikipedia.org/wiki/Lamb_vector),
- (optionally) its divergence
- on-the-fly or via postProcess utility
- for a given volVectorField (one per functionObject entry)
- Why:
The motivation is the literature-reported quantitative connection
between the Lamb vector (divergence) and the spatially localised
instantaneous fluid motions, e.g. high- and low-momentum fluid
parcels, which possess considerable level of capacity to affect
the rate of change of momentum, and to generate forces such as drag.
- Verification:
- Smooth-wall plane channel flow case (Moser et al. 1999) by
- Curtis et al. (2008) On the Lamb vector divergence
in Navier–Stokes flows, doi:10.1017/S0022112008002760
- What's next:
- The verification-show case
- Extended code guide entry titled "Lamb vector"
- Related:
- "fvc::curl(U)^U" is computed twice when "divergence_" is on.
It will be reduced one.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/18ENH: foamHelp - added support for solvers2015-11-29T06:03:41ZAdminENH: foamHelp - added support for solvers- Added support for solvers
- Updated use of FOAM_ABORT - old code left commented in helpBoundary.C for now...- Added support for solvers
- Updated use of FOAM_ABORT - old code left commented in helpBoundary.C for now...Functionality migration from internal development lineMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/15ENH: Foam abort - reading from env(FOAM_ABORT) instead of caching value on co...2015-11-26T12:53:50ZAdminENH: Foam abort - reading from env(FOAM_ABORT) instead of caching value on constructionAs discussed - no longer caching value of FOAM_ABORT on construction of error class; instead, always read from FOAM_ABORT. Should be no perceived performance impact since this is only triggered on exit/abort.As discussed - no longer caching value of FOAM_ABORT on construction of error class; instead, always read from FOAM_ABORT. Should be no perceived performance impact since this is only triggered on exit/abort.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/611ENH: finiteArea: enable gradient caches2023-06-14T14:22:10ZKutalmış BerçinENH: finiteArea: enable gradient caches#### Summary
The gradient chaching functionality is enabled for the finite-area framework.
Example usage in `system/faSolution`:
```
cache
{ ...#### Summary
The gradient chaching functionality is enabled for the finite-area framework.
Example usage in `system/faSolution`:
```
cache
{
grad(h);
grad(Us);
}
```
#### Risks
- No change in existing input/output.
#### Metadata
- [x] linux64ClangDPInt32Opt (clang13)
- [ ] linux64GccDPInt32Opt
- [ ] linux64GccSPDPInt64Debug
- [ ] Alltest: No new error/No change in existing output
- [x] Test case: `$FOAM_TUTORIALS/finiteArea/liquidFilmFoam/cylinder`v2306Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/380ENH: finer granularity for handling functionObject failure (#1779)2020-08-06T16:15:10ZMark OLESENENH: finer granularity for handling functionObject failure (#1779)- additional "errors" entry with enumerated values
(default|warn|ignore|strict) for defining warning or error at
construct or runtime stage
- default : construct = warn, runtime = fatal
- warn : construct = warn, runtime = warn
-...- additional "errors" entry with enumerated values
(default|warn|ignore|strict) for defining warning or error at
construct or runtime stage
- default : construct = warn, runtime = fatal
- warn : construct = warn, runtime = warn
- ignore : construct = silent, runtime = silent
- strict : construct = fatal, runtime = fatal
The errors control can be added at the top-level and/or for individual
function objects.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/653ENH: fileOperation: fix fileOperation::nProcs to handle multiple candidates2023-12-18T15:59:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: fileOperation: fix fileOperation::nProcs to handle multiple candidatesAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/98ENH: Feature noise additions2017-03-16T05:16:22ZAdminENH: Feature noise additionsNoise model functionality updates
- optional writing for each output
- can now use relative or absolute paths for input/output data
- output data can be limited to lower and upper (user-selected) frequency bounds
- output paths updat...Noise model functionality updates
- optional writing for each output
- can now use relative or absolute paths for input/output data
- output data can be limited to lower and upper (user-selected) frequency bounds
- output paths updated to ensure not to overwrite output when processing multiple filesVersion v1706AdminAdminhttps://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/571ENH: Evapotranspiration utilities2022-12-08T11:36:30ZKutalmış BerçinENH: Evapotranspiration utilitiesEP1950EP1950v2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/567ENH: ensightToFoam: Ensight Gold mesh converter2022-11-07T21:26:38ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: ensightToFoam: Ensight Gold mesh converter# Ensight format mesh reading
This release adds an Ensight Gold mesh importer is supported. It can handle all cell shapes supported by the `foamToEnsight` converter. It currently gets given the geometry file name (geo`extension`). It su...# Ensight format mesh reading
This release adds an Ensight Gold mesh importer is supported. It can handle all cell shapes supported by the `foamToEnsight` converter. It currently gets given the geometry file name (geo`extension`). It supports both ascii and binary formats.
Supported keywords:
- `extents`
- `node id 'given', 'ignore', 'assign'`
- `node_ids`
- `element id 'given', 'ignore', 'assign'`
- `element_ids`
- `part`
- `coordinates`
- `tetra4`
- `pyramid5`
- `penta6`
- `hexa8`
- `nfaced`
- `tria3`
- `quad4`
- `nsided`
It does not support
- 2D (finite-area) meshes
- `block` structured meshes
- quadratic elements (e.g. `twenty node hexahedron`)
- faceZones
- baffles (they probably get merged away unless they are in the first part - not tested)
It reads all parts, combines all the cells (`tetra3`, `hexa8` etc) and determines the outside faces. It merges all the points using a geometric test (see below) and uses all faces (`tria3` etc.) to patch any outside faces. Patch names are the original part names with any illegal word symbol replaced by '_'. Any remaining outside faces get added to a `defaultFaces` patch of type `empty`.
## Options
- `mergeTol` : supply optional merge tolerance to get the correspondence between points of different parts. Default is 1e-10 of the bounding box of all points. Specifying 0 disables any point merging (and hence patching).
- `scale` : specify optional scaling for the coordinates. Default is no scaling. Scaling can e.g. be used if the mesh is specified in [mm] instead of [m].
- `keepHandedness` : by default the mesh reader will flip (non-polyhedral) cells with negative volume. It will display warning messages of the form
```
zero or negative pyramid volume:
```
Use the flag to disable this check and use the normal vertex numbering.
Source code
- application/utilities/mesh/conversion/ensightToFoamMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com