openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2016-10-04T09:28:30Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/65Output format2016-10-04T09:28:30ZMark OLESENOutput formatOutput changes (issues #253 , #254 , #255 , #256) as well as minor change (issue #257).
Usage of the new methods to be applied as a later patch.Output changes (issues #253 , #254 , #255 , #256) as well as minor change (issue #257).
Usage of the new methods to be applied as a later patch.Version v1612AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/601Optimization to ldu Matrix2023-05-10T10:10:40ZAlon ZameretOptimization to ldu Matrix## 1 Goal
The goal of this change is to improve the sparse solver in OpenFOAM in terms of computational efficiency and communication reduction.
The related modifications come in three categories:
- remove the redundant codes in **symG...## 1 Goal
The goal of this change is to improve the sparse solver in OpenFOAM in terms of computational efficiency and communication reduction.
The related modifications come in three categories:
- remove the redundant codes in **symGaussSeidelSmoother.C**.
- fuse the “ACf = Ax” with “coarseSources -= ACF” to get “coarseSources -=Ax” codes in **GAMGSolverSolve.C**.
- reduce the number of “Allreduce” in **PCG.C**.
## 2 Proposed Change and Results
### 2.1 symGaussSeidelSmoother.C
The symGaussSeidel runs the following algorithm:
- Forward: $x_i^{k+1}=\frac{1}{a_{ii}} (b-∑_{j=1}^{i-1}a_{ij} x_j^{k+1} -∑_{j=i+1}^na_{ij} x_j^k)$
- Backward: $x_i^{k+2}=\frac{1}{a_{ii}} (b-∑_{j=1}^{i-1}a_{ij} x_j^{k+1} -∑_{j=i+1}^na_{ij} x_j^{k+2})$
The realization in OpenFOAM is as follows:
![symgs](/uploads/e45b8885d2b60ea47033e38cd918a749/symgs.png)
We can see that the last step, i.e. $bPrime=bPrime-∑_{j=i+1}^n a_{ij} x_i^{k+2} $, is redundant. Mapping to the code realization, we can get the “distribute neighbor side …” step is redundant as long as forall facei > ownStartPtr[celli], uPtr[facei] > celli.
We test the modification on cavity 256*512 case. The results show that symgs operation improves by 5%,and the results keeps the same.
- Orginal: Total 28.19s , symGS time = 28.19*62.32% =17.568s
![symgsResult1](/uploads/7b0490eff481b9cf945de2ec4824bef9/symgsResult1.png)
- Modified: Total 27.39s , symGS time = 27.39*61.16% =16.75s
![symgsResult2](/uploads/1cfa3235edb4fae17fbffe39e5a52bf6/symgsResult2.png)
### 2.2 GAMGSolverSolve.C
Original code writes “ACf = Ax” together with “coarseSources -= ACF”. We can combine them together to get “coarseSources -=Ax”.
Furthermore, “ACF” is not used here. We can move the declaration of “ACF” to where it is needed. I think the declaration of ACF can be further simplified, which is done here.
The fusion and the move of the declaration will improve the performance (not much, but better than none) and reduce the kernel used.
### 2.3 PCG.C
The original PCG have three “Allreduce” procedure, which is the most time-consuming part when running large scale system. Note that the last “Allreduce” procedure is used to calculate the residual for convergence. Then we can move the last “Allreduce” procedure to the next iteration, and combine it with the first “Allreduce” procedure. The figure illustrates the aforementioned change.
![PCG](/uploads/3f289551df29e8425fe39809c828948a/PCG.png)
The proposed change is able to reduce iterNo/3 number of “Allreduce” process and iterNo number of “r” variable load at the cost of one more precondition. (iterNo:the number of iterations)
The proposed change will improve performance if
- run PCG for solving coarsest mesh.
- run PCG with preconditioner DIC/diagonal/none. (test with cavity512*512, Kunpeng 920 128cores, DIC preconditioned PCG)
- Orginal: Total 2.46s , shared memory MPI = 2.46*33.92% =0.83s
![PCGResult1](/uploads/1b9246942756e2ae021394605516f8f0/PCGResult1.png)
- Modified: Total 2.11s , shared memory MPI = 2.11*28.38% =0.6s
![PCGResult2](/uploads/33c64e8bd7f398a6557b80d29b9482f4/PCGResult2.png)
- run PCG with preconditioner GAMG with many cores or many iterations.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/369New Weber number cloud function object2020-06-11T14:00:37ZAndrew HeatherNew Weber number cloud function objectExample usage:
cloudFunctions
{
WeberNumber1
{
type WeberNumber;
}
}
This will calculate and write the Weber number field as a 'standard' cloud field, available for post-proces...Example usage:
cloudFunctions
{
WeberNumber1
{
type WeberNumber;
}
}
This will calculate and write the Weber number field as a 'standard' cloud field, available for post-processing alongside other lagrangian fields in the lagrangian/<cloudName> directory.
See example in `$FOAM_TUTORIALS/lagrangian/sprayFoam/aachenBomb/constant/sprayCloudProperties`v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/316New VOF multiphaseStabilizedTurbulence fvOption2019-12-19T08:46:51ZAndrew HeatherNew VOF multiphaseStabilizedTurbulence fvOption### Summary
Applies corrections to turbulence kinetic energy equation and turbulence viscosity field for incompressible multiphase flow cases.
Turbulence kinetic energy is over-predicted in incompressible VOF solvers at the phase i...### Summary
Applies corrections to turbulence kinetic energy equation and turbulence viscosity field for incompressible multiphase flow cases.
Turbulence kinetic energy is over-predicted in incompressible VOF solvers at the phase interface and throughout the water column in nearly-potential flow regions beneath surface waves.
This fvOption applies corrections based on the references:
Buoyancy source term in turbulence kinetic energy equation:
Devolder, B., Rauwoens, P., and Troch, P. (2017).
Application of a buoyancy-modified k-w SST turbulence model to
simulate wave run-up around a monopile subjected to regular waves
using OpenFOAM.
Coastal Engineering, 125, 81-94.
Correction to turbulence viscosity:
Larsen, B.E. and Fuhrman, D.R. (2018).
On the over-production of turbulence beneath surface waves in
Reynolds-averaged Navier-Stokes models
J. Fluid Mech, 853, 419-460
### Resolved bugs (If applicable)
See #1433
### Details of new models (If applicable)
The implementation is based on the form for the k-epsilon turbulence model.
Example usage:
multiphaseStabilizedTurbulence1
{
type multiphaseStabilizedTurbulence;
active yes;
multiphaseStabilizedTurbulenceCoeffs
{
// Optional coefficients
lambda2 0.1; // A value of 0 sets the nut correction to 0
Cmu 0.09; // from k-epsilon model
C 1.51; // model coefficient from k-omega model
alpha 1.36; // 1/Prt
}
}
The model `C` coefficient for the k-epsilon model equates to C2/C1 = 1.33; the (default) value of 1.51 comes from the k-omega model and is more conservative.
### Risks
Modular - low risk
### Credits
Thanks go to the Turbulence Technical Committee, and the useful discussions with and code testing by Bjarke Eltard-Larsen and David Fuhrman (Technical University of Denmark).v1912https://develop.openfoam.com/Development/openfoam/-/merge_requests/404New vibro-acoustic model suite2020-12-10T13:38:38ZSergio FerrarisNew vibro-acoustic model suite - New solver: `acousticFoam`
- New base finite-area region class: `regionFaModel`
- New base shell model classes:
- `vibrationShellModel`
- `thermalShellModel`
- New shell models:
- A vibration-shell model: `Kirchhoff... - New solver: `acousticFoam`
- New base finite-area region class: `regionFaModel`
- New base shell model classes:
- `vibrationShellModel`
- `thermalShellModel`
- New shell models:
- A vibration-shell model: `KirchhoffShell`
- A thermal-shell model: `thermalShell`
- New finite-area/finite-volume boundary conditions:
- `clampedPlate`
- `timeVaryingFixedValue`
- `acousticWaveTransmissive`
- New base classes for `fvOption` of finite-area methods: `faOption`
- New `faOption`s:
- `contactHeatFluxSource`
- `externalFileSource`
- `externalHeatFluxSource`
- `jouleHeatingSource`
- New tutorial: `compressible/acousticFoam/obliqueAirJet`v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/537New solid body motion mesh update optimisations2022-05-19T16:19:48ZAndrew HeatherNew solid body motion mesh update optimisations### Summary
New/refactored code to enable partial geometry updates for solid-body motion cases.
### Details of new models (If applicable)
Adds a new `solidBody` geometry scheme, applicable for e.g. rotating AMI/ACMI cases:
```
geomet...### Summary
New/refactored code to enable partial geometry updates for solid-body motion cases.
### Details of new models (If applicable)
Adds a new `solidBody` geometry scheme, applicable for e.g. rotating AMI/ACMI cases:
```
geometry
{
type solidBody;
// Optional
partialUpdate yes; // default = yes
cacheMotion yes; // default = yes
}
```
Instead of performing a complete mesh clear-out we selectively update only the geometry attached to moving points, under the assumption that there are no topological updates/the motion can be described as solid-body motion.
Performance improvements (time) are case specific, e.g. the smaller the fraction of moving cells compared to the total cell count, the larger the benefit for the mesh update phase.
The additional entries control:
- `partialUpdate` : if set to `false`, perform a complete mesh clear-out on mesh changes
- `cacheMotion` : if set to `true`, cache the addressing for the moving points, faces and cells across all time steps
**Backwards compatibility**
The `basic` option is the default and is applied if the `geometry` sub-dictionary is not supplied:
```
geometry
{
type basic;
}
```
Selecting this option should recover v2112 (and earlier versions) behaviour.
### Risks
- Refactored mesh updates
- mesh flux is now calculated by the `fvGeometryScheme`
- Added partial geometry updates
- see `primitiveMeshTools.H` functions `updateFaceCentresAndAreas` and `updateCellCentresAndVols`
- Need to test `snappyHexMesh` cases - the updates did not initially play nicely with the layer addition phase
### Testing
- Tests performed on:
- `pimpleFoam/RAS/propeller tutorial`
- `singleWheel` (internal)v2206Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/268New QRMatrix, HessenbergMatrix and EigenMatrix2019-11-12T20:35:38ZKutalmış BerçinNew QRMatrix, HessenbergMatrix and EigenMatrixAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/541New function objects2022-05-25T23:18:21ZAndrew HeatherNew function objects## New function objects
### multiFieldValue
- Previously, the `multiFieldValue` function object was limited to operate on lists of `fieldValue` function objects.
- Any function objects that generate results can now be used, e.g.
```
p...## New function objects
### multiFieldValue
- Previously, the `multiFieldValue` function object was limited to operate on lists of `fieldValue` function objects.
- Any function objects that generate results can now be used, e.g.
```
pressureAverage
{
type multiFieldValue;
libs (fieldFunctionObjects);
operation average;
functions
{
inlet
{
type surfaceFieldValue;
operation areaAverage;
regionType patch;
name inlet;
fields (p);
writeFields no;
writeToFile no;
log no;
resultFields (areaAverage(inlet,p));
}
outlet
{
type surfaceFieldValue;
operation areaAverage;
regionType patch;
name outlet;
fields (p);
writeFields no;
writeToFile no;
log no;
}
average
{
type valueAverage;
functionObject testSample1;
fields (average(p));
writeToFile no;
log no;
}
}
}
```
Test case : [filter-multiFieldValue.tgz](/uploads/8a6ad51f582260e625ebbebe5313580f/filter-multiFieldValue.tgz) - see `system/pressureDifference` function object
### particleZoneInfo
Reports cloud information for particles passing through a specified cell zone.
Example usage:
```
cloudFunctions
{
particleZoneInfo1
{
type particleZoneInfo;
cellZone leftFluid;
// Optional entries
//writer vtk;
}
}
```
Results are written to file:
- `\<case\>/postProcessing/lagrangian/\<cloudName\>/\<functionName\>/\<time\>`
```
# cellZone : leftFluid
# time : 1.0000000000e+00
#
# origID origProc (x y z) time0 age d0 d mass0 mass
```
Where
- `origID` : particle ID
- `origProc` : processor ID
- `(x y z)` : Cartesian co-ordinates
- `time0` : time particle enters the `cellZone`
- `age` : time spent in the `cellZone`
- `d0` : diameter on entry to the `cellZone`
- `d` : current diameter
- `mass0` : mass on entry to the `cellZone`
- `mass` : current mass
If the optional `writer` entry is supplied, cloud data is written in the specified format.
During the run, output statistics are reported after the cloud solution, e.g.:
```
particleZoneInfo:
Cell zone = leftFluid
Contributions = 257
```
Here, `Contributions` refers to the number of incremental particle-move contributions recorded during this time step. At write times, the output is extended, e.g.:
```
particleZoneInfo:
Cell zone = leftFluid
Contributions = 822
Number of particles = 199
Written data to "postProcessing/lagrangian/reactingCloud1/
```
Test case: [filter-particleZoneInfo.tgz](/uploads/4872ea54688374b5a7e475015f3efe93/filter-particleZoneInfo.tgz) - see `constant/reactingCloud1Properties`v2206Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/82New feature extract eulerian particles2016-12-14T15:57:12ZAdminNew feature extract eulerian particlesNew functionality to extract particle data from multiphase calculations and replay the data in lagrangian cases, using both the raw input particle data, and data processed into a (smaller) set of injection locations.New functionality to extract particle data from multiphase calculations and replay the data in lagrangian cases, using both the raw input particle data, and data processed into a (smaller) set of injection locations.Version v1612AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/516New "exprField" function object2021-12-10T14:46:34ZMark OLESENNew "exprField" function object- provides a simple means of defining/modifying fields.
For example,
```
<name1>
{
type exprField;
libs (fieldFunctionObjects);
field pTotal; //<- output field
expression "p + 0.5*(rho*magSqr(U))";
dime...- provides a simple means of defining/modifying fields.
For example,
```
<name1>
{
type exprField;
libs (fieldFunctionObjects);
field pTotal; //<- output field
expression "p + 0.5*(rho*magSqr(U))";
dimensions [ Pa ];
}
// modify the above
<name1>
{
type exprField;
libs (fieldFunctionObjects);
field pTotal; //<- input/output field (for modify)
action modify;
// Static pressure only in these regions
fieldMask
#{
(mag(pos()) < 0.05) && (pos().y() > 0)
|| cellZone(inlet)
#};
expression "p";
};
```
![exprFieldFunctionObject](/uploads/bc7b302f3332186336d430ed8f29c60a/exprFieldFunctionObject.png)v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/377New Evap-Cond Lagrangian model (FuchsKnudsen) for solution (liquid + solid)...2020-09-22T15:37:04ZSergio FerrarisNew Evap-Cond Lagrangian model (FuchsKnudsen) for solution (liquid + solid) dropletsAdding evap-cond Lagrangian model for solution droplets
1) Adding LiquidEvapFuchsKnudsen model for Lagrangian evaporation.
This models is based on a diffusion type of evaporation/
condensation on particles composed...Adding evap-cond Lagrangian model for solution droplets
1) Adding LiquidEvapFuchsKnudsen model for Lagrangian evaporation.
This models is based on a diffusion type of evaporation/
condensation on particles composed of solution (liquid + solid).
2) Adding modes of calculating the particle rho and volume change.
The new keyword in constantProperties is volumeUpdateMethod
which three options:
a) constantRho
b) constantVolume
c) updateRhoAndVol
3) The entry rho0 is now optional for multicomponent parcels.
If defined , it is used but if it is not the actuall mixture
provided is used to calculate rho0 of the particle
T0 is still used as initial T and Cp0 is over-written in the
multi-component cloudAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/39Multiple updates for run-time post-processing functionality2023-12-07T19:01:57ZPrashant SonakarMultiple updates for run-time post-processing functionalityAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/196more consistent use of dimensioned Zero2018-04-03T19:30:32ZMark OLESENmore consistent use of dimensioned ZeroReduced clutter when creating and zero initializing volume fieldsReduced clutter when creating and zero initializing volume fieldsv1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/566More consistent use of combineReduce, simpler and/or reductions2022-11-08T16:48:23ZMark OLESENMore consistent use of combineReduce, simpler and/or reductions- update code base to reflect the consolidated list/map reductions
- replace old code use of `returnReduce(list.size(), sumOp<label>())` in favour of `returnReduceOr(list.size())` which is cleaner to write/understand and also marginally...- update code base to reflect the consolidated list/map reductions
- replace old code use of `returnReduce(list.size(), sumOp<label>())` in favour of `returnReduceOr(list.size())` which is cleaner to write/understand and also marginally more efficient
General overview under
https://develop.openfoam.com/Development/openfoam/-/wikis/coding/patterns/parallel
- [broadcast](https://develop.openfoam.com/Development/openfoam/-/wikis/coding/patterns/parallel#broadcast)
- [reductions](https://develop.openfoam.com/Development/openfoam/-/wikis/coding/patterns/parallel#plain-reductions)
- [more reductions](https://develop.openfoam.com/Development/openfoam/-/wikis/coding/patterns/parallel#other-reductions)v2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/315MISC: RANS model, TUT, BUG, DOC changes2019-12-18T16:16:12ZKutalmış BerçinMISC: RANS model, TUT, BUG, DOC changesAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/387Miscellaneous code changes - Nov 202020-11-13T09:22:38ZKutalmış BerçinMiscellaneous code changes - Nov 20PS: approval/feedback please @mark @Sergio @andy @Prashant
heatTransferCoeff -> @SergioPS: approval/feedback please @mark @Sergio @andy @Prashant
heatTransferCoeff -> @SergioAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/663Misc. changes in the regionFaModels2024-02-23T15:54:11ZKutalmış BerçinMisc. changes in the regionFaModelsAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/661Misc. changes in the finite-area module2024-03-05T18:14:15ZKutalmış BerçinMisc. changes in the finite-area moduleAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/585Misc. changes in finite-area methods2023-02-08T14:44:32ZKutalmış BerçinMisc. changes in finite-area methods#### Acknowledgement
OpenCFD would like to acknowledge and thank **Matthias Rauter** for his help and discussions. Highly appreciated.#### Acknowledgement
OpenCFD would like to acknowledge and thank **Matthias Rauter** for his help and discussions. Highly appreciated.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/672misc changes for reduced stringstream and MPI overhead2024-03-07T18:11:39ZMark OLESENmisc changes for reduced stringstream and MPI overheadv2406Kutalmış BerçinKutalmış Berçin