openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2023-03-03T16:41:20Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/596Improved point-cell and cell-point topology methods2023-03-03T16:41:20ZAlon ZameretImproved point-cell and cell-point topology methods# Goal
The goal of this change is to reduce the runtime of the `pointCells()` and `cellPoints()` methods in the `primitiveMesh` class, which calculate the point-to-cell and cell-to-point addressing, respectively.
# Proposed Change
The...# Goal
The goal of this change is to reduce the runtime of the `pointCells()` and `cellPoints()` methods in the `primitiveMesh` class, which calculate the point-to-cell and cell-to-point addressing, respectively.
# Proposed Change
The `pointCells()` currently calculates the topology using the private method `calcPointCells()`, which utilizes the method `labels()` in the `cell` class. This method introduces significant overhead and reduces performance. The `cellPoints()` method currently calls the `pointCell()` method and inverts the result.
The proposed solution implements the `cellPoints()` method directly using a more efficient algorithm that makes use of the `bitset` data class to mark points that have already been found. Then, the `pointCells()` method is implemented by calling `cellPoints()` and inverting the result. As can be seen below, our implementation improves performance in all cases, even if the user only wants the point-cell topology.
# Results
The speedup values were calculated by running both the current version and the new version on structured cube meshes of varying sizes. It can be seen that the speedup remains constant among all the different mesh sizes.
In the testing, the meshes began without either one of the topologies present. Then 3 different cases were tested:
1. The user wants only point-cell topology
- Speedup = 1.4x
2. The user wants only cell-point topology
- Speedup = 2.4x
3. The user wants both topologies
- Speedup = 1.7x
![Screenshot](/uploads/f817bd3f389edff96fe6c9a62d6146b5/Screenshot.png)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/594Draft: use sparse storage and data exchange for PstreamBuffers2023-06-22T12:22:33ZMark OLESENDraft: use sparse storage and data exchange for PstreamBuffersChanges the PstreamBuffers storage to a Map of buffers and use NBX for exchanging sizes.Changes the PstreamBuffers storage to a Map of buffers and use NBX for exchanging sizes.v2306Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/593Field functions for lerp and clamp. Add clamping as Field methods2023-02-21T09:17:59ZMark OLESENField functions for lerp and clamp. Add clamping as Field methodsTo improve data locality and simplify calling code, now have `lerp()` and `clamp()` as free functions working on fields. Both can be composed as a SIMD type of operation (with three operands) and applied within the fields loops instead o...To improve data locality and simplify calling code, now have `lerp()` and `clamp()` as free functions working on fields. Both can be composed as a SIMD type of operation (with three operands) and applied within the fields loops instead of being composed as separate field operations.
- Having `lerp` turns out to only be moderately useful, since most of the schemes have already unrolled the operation inside. However, it is still quite convenient when composing (for example) mixed boundary conditions or combining patch internal and neighbour values.
- The `clamp` method is used in several more places, quite commonly in multi-phase routines to enforce a strict 0-1 boundness.
Since clamping of field values is a quite useful property, in-place clamping has been added as field methods directly:
- clamp_min(...), clamp_max(...), clamp_range(...)
The frequently required 0-1 bounding can be use succinctly with the `zero_one` dispatch tag. For example,
```
alpha.clamp_range(zero_one{});
```
Tip: with flow switching (eg, inlet/outlet) the `lerp` function can be combined with `pos0` to define a selector. Eg,
```
lerp(a, b, pos0(phi))
// vs.
a*neg(phi) + b * pos0(phi)
```v2306Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/592Pstream improvements for more flexibility. Non-blocking consensus exchange2023-02-09T12:35:30ZMark OLESENPstream improvements for more flexibility. Non-blocking consensus exchangeMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/591BUG: extraConvection in ATC missing a multiplication with ATClimiter2023-02-03T15:36:19ZVaggelis PapoutsisBUG: extraConvection in ATC missing a multiplication with ATClimiter### Resolved bugs (If applicable)
The bug is described in #2687
In the 'standard' and 'UaGradU' options for the ATC term of the adjoint equations, there is an option to add 'aritificial dissipation', by adding and subtracting a multip...### Resolved bugs (If applicable)
The bug is described in #2687
In the 'standard' and 'UaGradU' options for the ATC term of the adjoint equations, there is an option to add 'aritificial dissipation', by adding and subtracting a multiple of the adjoint convection term with different discretizations. The implicit part was not multiplied with the ATClimiter whereas the explicit one was, leading to mismatched contributions in the areas affected by the ATClimiter, which could affect the sensitivity derivatives.
This can be replicated using the sbend tutorial under
$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/sensitivityMaps/sbend/turbulent/lowRe/singlePoint
In the figures that follow, 'n' stands for nMask and 'e' for extraConvection in the setup of the ATC model. As 'n' increases, the sensitivity map should tend towards that of canceling the ATC everywhere. With the previous code behavior, this was not the case when $`n \neq 0, e \ne 0`$ (figure at the bottom left). The expected behavior is retrieved with the current fix (figure at the bottom right).
![sbend_ATC](/uploads/ae119cb31e9f40f288376a9f90dc9725/sbend_ATC.png)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/590ENH: wallDistAddressing: wall distance which stores addressing.2023-05-30T17:10:58ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: wallDistAddressing: wall distance which stores addressing.### Summary
In some physical models the distance-to-the-nearest-wall is used which involves calculating the nearest wall face. Some models additionally use the normal at that nearest wall face ('reflection vector') or even non-geometry ...### Summary
In some physical models the distance-to-the-nearest-wall is used which involves calculating the nearest wall face. Some models additionally use the normal at that nearest wall face ('reflection vector') or even non-geometry data (e.g. y+ in the `vanDriest` LES delta model).
The normal algorithm uses the same method (`meshWave`) to transport both the originating face centre (to decide on the nearest) and any additional properties (normal, y+). The problem with this method is that any field-dependent data (e.g. y+) needs to go through the whole algorithm even though the geometry stays constant.
In this merge request there is a new wall distance calculation method which transports the originating face centres and addressing. This addressing can then be stored and used to get any value onto the internal field.
As a test the `pipeCyclic` tutorial case was modified. In the figures below black is the original geometry with a rotational cyclic from left to right. Orange is the original geometry transformed by 90 degrees to show the effect of the rotation. Pink is a new set of wall baffles (these are the only wall faces). The green lines are from the cell centres to the nearest wall. As can be seen the cells close to the left of the original geometry find their nearest on the transformed geometry.
![nearest](/uploads/1aec1f3dde66f4d73afbd7f1569daf4c/nearest.png)
Similar, visualising the normals shows that it takes the corresponding normals of the rotated geometry
![normals](/uploads/412703afc080d28b1d8d524224d59a96/normals.png)
### Resolved bugs (If applicable)
https://develop.openfoam.com/Development/openfoam/-/issues/2648
### Details of new models (If applicable)
- `wallDistAddressing::New` instead of `wallDist::New`
- stores distance `y()` and addressing (including transformations)
- contains helper functions to map data on selected patches onto internal field
- requires https://develop.openfoam.com/Development/openfoam/-/merge_requests/589 to have named MeshObjects (if e.g. distance to non-wall patches is to be stored)
- used in `vanDriest` `LESdelta`
- used in `meshWaveAddressing` wall-distance calculation. In `system/fvSchemes`:
```
wallDist
{
method meshWaveAddressing;
nRequired true;
}
```
- debugging : set DebugSwitches for `wallDistAddressing`:
- 1 : report number of untransformed and transformed wall faces
- 2 : dump `nearest.obj` file with lines/normals to/from nearest wall face
### Risks
- slightly different behaviour at y+ 500. Before it would never visit cells surrounded by cells with y+ 500. In this version it calculates y+ everywhere and truncates afterwards. In tests we have not seen any difference.
- requires additional storage for transformations (sized with the number of wall faces and number of transformations)
- transformation support is only tested for a single transformationMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/589ENH: MeshObject: specify name (instead of typeName)2023-02-01T20:45:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: MeshObject: specify name (instead of typeName)### Summary
MeshObjects are a mesh-related singleton. Sometimes useful to have multiple versions.### Summary
MeshObjects are a mesh-related singleton. Sometimes useful to have multiple versions.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/588Draft: New renumbering based on Hamiltonian path2023-06-23T07:39:56ZAlon ZameretDraft: New renumbering based on Hamiltonian path### Summary
Included a new renumbering method called 'hpathRenumber' which reorder the mesh cells using an Hamiltonian path approach.
### Details of new models
Hamiltonian path is a path that traverses through the mesh faces and visi...### Summary
Included a new renumbering method called 'hpathRenumber' which reorder the mesh cells using an Hamiltonian path approach.
### Details of new models
Hamiltonian path is a path that traverses through the mesh faces and visits each cell exactly once. The Hamiltonian path approach tries to find such a path and renumber the mesh accordingly. This method ensures that after the mesh renumbering, consecutive cells in memory will likely share a common geometrical face. This in turn may allow for more efficient memory access and better vectorization performances when traversing the mesh.
![2D_Cylinder_Hpath](/uploads/90b36b3ca4136da32aaa93090c9300c0/2D_Cylinder_Hpath.png)
### Usage
Described below is the renumberMethodDict example used to apply Hamiltonian path renumbering:
```
method hpath;
hpathCoeffs
{
layered true;
}
```
The 'layered' argument (default true) controls whether the algorithm will separate the mesh cells into different 'layers' (otherwise, all cells are considered to be within the same layer). The layer separation approach is known to obtain better results and improved run-time for 3D cases, while 2D cases where a simpler Hamiltonian path may exist will benefit from avoiding the layer separation.
The algorithm will than try to find an Hamiltonian path traversing through all the cells sharing the same layer, and report the Hamiltonian path accuracy obtained.
The path accuracy is defined as the percentage of consecutive cells in the renumbered order that share a common face.v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/587Draft: New decomposition method (multiNodeDecomp)2023-06-23T07:40:04ZAlon ZameretDraft: New decomposition method (multiNodeDecomp)### Summary
A new decomposition method 'multiNodeDecomp' which extends the capabilities of the multi-level decomposition method found within OpenFOAM while maintaining full backwards compatibility.
The multiNodeDecomp allow users contro...### Summary
A new decomposition method 'multiNodeDecomp' which extends the capabilities of the multi-level decomposition method found within OpenFOAM while maintaining full backwards compatibility.
The multiNodeDecomp allow users control over the properties of each node within the decomposition tree, as opposed to multi-level decomposition which supports level-based modifications.
### Details of new decomposition method
The multiNodeDecomp method adds the following capabilities:
1. Support decomposition to un-even nodes by changing the number of children of each node. For example:
```
multiNodeCoeffs {
method metis;
domains (3 4);
domains[0] (8);
}
```
In the example above, the mesh will be decomposed into 3 domains, where the first domain (domain[0]) will be further decomposed into 8 subdomains, while the remaining 2 domains will be decomposed into 4 subdomains only.
This will result in a total of 20 subdomains.
Note that the user passes a list value, which allows to have a different number of levels under different branches of the decomposition tree.
2. Simplified interface for decomposition weights - uniform/relative weight distribution may be used to initialize the weight of each node. The user may later overwrite any of the nodes weight.
```
weightsInitialization relative;
weight[0][3] 2;
```
'Uniform' initialization will recursively set all of the nodes weights to 1, while the 'Relative' initialization sets each nodes weight to the number of leaves in its decomposition subtree.
The weight of a node is then used during its parent's decomposition to control the sub-mesh size it will receive.
3. Modify the nodes decomposition method:
```
method[2] {
method scotch;
coeffs {
...
}
}
```
This will overwrite the method of the third subdomain of the root to use scotch and the given coefficients.
### Syntax
multiNodeDecomp supports setting the decomposition properties above on a level scope (parameter[] value) or on a node scope (parameter[#nodeIndex] value).
The square brackets indicate indices of the children we want to modify (0 based indexing). The user may specify ranges by using a hyphen ([0-3]) or specifying all of the children by using empty brackets ([]).v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/586ENH: pureZoneMixture: different mixture properties according to cellZone2022-12-14T15:39:18ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: pureZoneMixture: different mixture properties according to cellZone### Summary
Use a different mixture on a per-cell basis.
### Details of new models (If applicable)
In the `thermoPhysicalProperties` one can now select the new `pureZoneMixture` model. It is a drop-in replacement for `pureMixture` wh...### Summary
Use a different mixture on a per-cell basis.
### Details of new models (If applicable)
In the `thermoPhysicalProperties` one can now select the new `pureZoneMixture` model. It is a drop-in replacement for `pureMixture` where the mixture properties itself are sub selected by cellZones. In below example (for a solid mesh) there are two cellZones, `heater1` and `heater2`. The second, `heater2` has slightly different properties:
```
thermoType
{
type heSolidThermo;
mixture pureZoneMixture; //pureMixture;
transport constIso;
thermo hConst;
equationOfState rhoConst;
specie specie;
energy sensibleEnthalpy;
}
mixture
{
heater1
{
specie
{
molWeight 50;
}
transport
{
kappa 80;
}
thermodynamics
{
Hf 0;
Cp 450;
}
equationOfState
{
rho 8000;
}
}
heater2
{
//- Start off from heater1 properties
${heater1}
//- Selectively overwrite properties
equationOfState
{
rho 4000;
}
}
}
```
### Risks
- the input works with the usual explicit boundary conditions (`compressible::turbulentTemperatureRadCoupledMixed`) for `chtMultiRegionFoam`. The only difference is that the per-cell properties are looked up through the cellZone the cell is in.
- the two cellZones can also not be separated (i.e. share faces) in which case attention has to be paid to the interpolation scheme (e.g. `harmonic`)Mark OLESENMark OLESENhttps://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/584ENH: dynamicContactAngleForce: new finite-area contact-angle force model2022-12-09T13:09:22ZKutalmış BerçinENH: dynamicContactAngleForce: new finite-area contact-angle force modelDocumentation: [MR584-contact-line-movement.pdf](/uploads/4630ced2e0840306c54a220827cab6b4/MR584-contact-line-movement.pdf)
Test case: [MR584-contact-line-movement.zip](/uploads/d8e429759478273657c4dadbe94f76fe/MR584-contact-line-moveme...Documentation: [MR584-contact-line-movement.pdf](/uploads/4630ced2e0840306c54a220827cab6b4/MR584-contact-line-movement.pdf)
Test case: [MR584-contact-line-movement.zip](/uploads/d8e429759478273657c4dadbe94f76fe/MR584-contact-line-movement.zip)
##### Metadata
EP#1996
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/583ENH: added option to control log frequency of lagrangian calculations2022-12-09T10:05:42ZAndrew HeatherENH: added option to control log frequency of lagrangian calculations### Summary
Cross ref: EP#1945
Lagrangian cloud calculations can generate significant amounts of reporting, e.g.
Solving2-D cloud reactingCloud1
Cloud: reactingCloud1
Current number of parcels = 994
Curre...### Summary
Cross ref: EP#1945
Lagrangian cloud calculations can generate significant amounts of reporting, e.g.
Solving2-D cloud reactingCloud1
Cloud: reactingCloud1
Current number of parcels = 994
Current mass in system = 0.009735873844
Linear momentum = (0.0001652067978 0.0001039875528 0)
|Linear momentum| = 0.0001952093676
Linear kinetic energy = 0.0001660812145
Average particle per parcel = 19.21387643
Injector model1:
- parcels added = 994
- mass introduced = 0.01
Parcel fate: system (number, mass)
- escape = 0, 0
Parcel fate: patch (walls|cyc.*) (number, mass)
- escape = 0, 0
- stick = 0, 0
Parcel fate: patch (inlet|outlet) (number, mass)
- escape = 0, 0
- stick = 0, 0
Temperature min/max = 275.039299, 275.4193813
Mass transfer phase change = 0.000264126156
Mass transfer devolatilisation = 0
Mass transfer surface reaction = 0
If multiple injectors and/or more interaction patches are present, the quantity of output information can increase dramatically.
For some workflows it can be beneficial to reduce the amount of output by reporting this data every `n` time steps instead of every step.
### Details of new models (If applicable)
Added an optional `logFrequency` keyword to the cloud solution input dictionary, e.g. in the `<case>/constant/*CloudProperties`
solution
{
active true;
coupled false;
transient yes;
cellValueSourceCorrection off;
maxCo 0.3;
logFrequency 3; // <--- NEW ENTRY
...
}
The value is set to 1 by default to maintain backwards compatibility.
### Risks
- Multiple small changes across the code - should be low risk.
- use of `Log_` vs `Log` annoying but needed for use in templated code - suggestions welcomev2212Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/582Cleaner separation global/local/self communication, cleaner responsibility fo...2022-12-05T19:08:24ZMark OLESENCleaner separation global/local/self communication, cleaner responsibility for fileHandler ownershipv2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/581ENH: KinematicSurfaceFilm: add option to specify interacting parcel types2022-12-01T12:52:07ZKutalmış BerçinENH: KinematicSurfaceFilm: add option to specify interacting parcel typesEP2019
Test case: [kinematicParcelFoam-splashPanelFilm.zip](/uploads/430a45abf4d47c4bd01b11b43197822f/kinematicParcelFoam-splashPanelFilm.zip)
This changeset adds a new entry 'parcelTypes' which can specify the list of
parcel type IDs ...EP2019
Test case: [kinematicParcelFoam-splashPanelFilm.zip](/uploads/430a45abf4d47c4bd01b11b43197822f/kinematicParcelFoam-splashPanelFilm.zip)
This changeset adds a new entry 'parcelTypes' which can specify the list of
parcel type IDs interacting with a surface film. If the entry
is omitted, all particle types are considered.
```
surfaceFilmModel kinematicSurfaceFilm;
kinematicSurfaceFilmCoeffs
{
interactionType absorb;
// Optional list of participating parcel IDs
parcelTypes (10);
}
```
To set the parcel type by injector, 'injectorID' entry can be used
when specifying the injector models, e.g.
```
injectionModels
{
model1
{
type <injectionModelType>;
// Optional injector ID
// - if ommitted, parcels use '-1'
injectorID 10;
...
}
}
```
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/580ENH: Brun dripping film injection2022-12-01T13:58:35ZKutalmış BerçinENH: Brun dripping film injectionEP2009
Test case: [dripping-test.zip](/uploads/972e684819c0a3b9b833e0d68e1d7560/dripping-test.zip)
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorEP2009
Test case: [dripping-test.zip](/uploads/972e684819c0a3b9b833e0d68e1d7560/dripping-test.zip)
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/579ENH: solidIsothermalReactionRate: new solid reaction rate model2022-11-29T14:31:17ZKutalmış BerçinENH: solidIsothermalReactionRate: new solid reaction rate modelEP2005, EP1629
##### Usage example
In `combustion/fireFoam/LES/simplePMMApanel/constant/panelRegion/reactions`:
```
reactions
{
_tmp_
{
#include "<constant>/panelRegion/thermo.solid"
}
charReaction
{
...EP2005, EP1629
##### Usage example
In `combustion/fireFoam/LES/simplePMMApanel/constant/panelRegion/reactions`:
```
reactions
{
_tmp_
{
#include "<constant>/panelRegion/thermo.solid"
}
charReaction
{
type irreversibleIsothermalSolidReaction;
reaction "PMMA = gas";
C <scalar>;
Tpc <scalar>;
Elat <scalar>;
Cp ${../_tmp_/PMMA/thermodynamics/Cp};
}
#remove _tmp_
}
```
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorMark 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/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 Heather