openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2023-02-01T20:45:49Zhttps://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/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-02-06T14:39:43ZMattijs 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/593Field functions for lerp and clamp. Add clamping as Field methods2023-02-07T17:56:00ZMark 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-07T23:28:51ZMark 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/588New renumbering based on Hamiltonian path2023-01-31T15:38:53ZAlon ZameretNew 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.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/587Draft: New decomposition method (multiNodeDecomp)2023-01-05T11:38:41ZAlon 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 ([]).Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/556Draft: unsteady adjoint functionality2022-12-13T12:49:35ZVaggelis PapoutsisDraft: unsteady adjoint functionality### Summary
Introduced unsteady adjoint functionality. Currently supports full storage of the primal time-series or utilization of binomial checkpointing.
This branch also serves as a fetching point for the profiling and improvement o...### Summary
Introduced unsteady adjoint functionality. Currently supports full storage of the primal time-series or utilization of binomial checkpointing.
This branch also serves as a fetching point for the profiling and improvement of the unsteady adjoint code during the exaFoam project.
### Details of new models
- The unsteady adjoint equations are integrated backwards in time. Since each adjoint time-step requires the primal solution of that time-step to be known, schemes for managing the storage/retrieval of the entire flow series are necessary. These are implemented through the primalStorage class and its derived ones. The latter manipulate a new class of fields, called compressedGeometricFields, which provide hooks for compressing/decompressing a field during the time integration of the primal/adjoint equations. The method used for compressing/decompressing is run-time selectable.
- The current commit provides the shortGeometricField implementation which avoids the storage of patchFields that can be retrieved from the internalField (e.g. coupled, zeroGradient, symmetry, etc), to cut on the storage requirements. More elaborate compression approaches will be included in the future, during the exaFoam project.
- Two primalStorage options are included: compressedFullStorage and binomialCheckPointing.
- compressedFullStorage stores the entire flow time-series, potentially by compressing each time-step (only the above-mentioned short approach is available for the moment).
- binomialCheckPointing is based on the homonymous algorithm proposed in
\verbatim
Wang, Q., Moin, P., & Iaccarino, G..
Minimal Repetition Dynamic Checkpointing Algorithm for
Unsteady Adjoint Calculation (2009).
SIAM Journal on Scientific Computing, 31(4), 2549-2567.
10.1137/080727890,
\endverbatim
which stores the solution of the flow equations in a predefined
number of time-steps, named checkpoints. During the
backwards-in-time integration of the adjoint equations, if the
primal solution at a certain time-step is not available, it is
retrieved by re-computing the primal flow field starting from the
closest checkpoint. Checkpoints are optimally distributed
throughout the time-series to invoke the least number of flow
recomputations during the backwards-in-time solution of the
adjoint equations. Binomial checkpointing is the current state of
the art though its re-computation cost frequently amounts for an
extra solution of the flow equations in medium-to-large cases.
- The adjoint to the PISO and PIMPLE solvers, along with their solverControl variants, are additionally included.
- Objective functions are integrated in time, through appropriate entries in the dictionaries defining them.
Authored by Andreas Margetis and reviewed by Vaggelis Papoutsis, with earlier contributions from Dr. Ioannis Kavvadias.v2306Vaggelis PapoutsisVaggelis Papoutsishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/526Draft: Resolve "ENH: cyclicACMI have optional search distance"2022-06-01T08:14:25ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comDraft: Resolve "ENH: cyclicACMI have optional search distance"Closes #2378Closes #2378Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/525Draft: Extend splitMeshRegions to automatically create AMI inter-region patches2022-02-17T12:01:17ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comDraft: Extend splitMeshRegions to automatically create AMI inter-region patches### Summary
splitMeshRegions by default creates one-to-one mapped patches between regions. This adds the option to generate AMI type mapped patches instead.
### Resolved bugs (If applicable)
#2251
### Details of new models (If appl...### Summary
splitMeshRegions by default creates one-to-one mapped patches between regions. This adds the option to generate AMI type mapped patches instead.
### Resolved bugs (If applicable)
#2251
### Details of new models (If applicable)
The new functionality is through the `autoPatch` command line option:
```
splitMeshRegions -autoPatch '(myInterfaces*)'
```
This will detect disconnected regions of the mesh and will attempt matching the 'myInterfaces*' patches using an AMI method. Any successful match will result in the matching faces to be put into a mapped type patch with `nearestPatchFaceAMI` as the inter-region mapping method.
### Risks
The logic is a bit more complex. There are unknowns about the behaviour of AMI type matching (it currently has no distance limit) but a different AMI matching method can be used using the `-AMIMethod` option.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/517Draft: ENH: PatchInjectionModel - added new parcel initial velocity options2021-12-14T14:15:55ZAndrew HeatherDraft: ENH: PatchInjectionModel - added new parcel initial velocity optionsThe 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
...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 tutorialv2112https://develop.openfoam.com/Development/openfoam/-/merge_requests/514Draft: Resolve "patchProbes output original point and distance"2021-12-09T08:56:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comDraft: Resolve "patchProbes output original point and distance"Closes #2291Closes #2291Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/513Draft: Resolve "patchProbes output original point and distance"2021-12-09T08:56:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comDraft: Resolve "patchProbes output original point and distance"Closes #2291Closes #2291Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/506turbulentTemperatureRadCoupledMixed allow Function1 for kappa2021-12-02T08:53:16ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comturbulentTemperatureRadCoupledMixed allow Function1 for kappa### Summary
- allow PatchFunction1 for kappa, alpha
- allow PatchFunction for thicknessLayer, kappaLayer
### Resolved bugs (If applicable)
#2277
### Risks
New keyword:
'kappaLayer', 'thicknessLayer' to specify a PatchFunction1 fo...### Summary
- allow PatchFunction1 for kappa, alpha
- allow PatchFunction for thicknessLayer, kappaLayer
### Resolved bugs (If applicable)
#2277
### Risks
New keyword:
'kappaLayer', 'thicknessLayer' to specify a PatchFunction1 for additional resistance.Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/472Draft: ENH: relative velocity usage for porosity in MRF regions2021-12-15T10:52:37ZAndrew HeatherDraft: ENH: relative velocity usage for porosity in MRF regionsRelated to #1652 - updates porosity calculation when used with MRF to use relative velocity
Test case from bug report: [rotatingCylinders-test.tgz](/uploads/49641463ba3d523874517a126aa32293/rotatingCylinders-test.tgz)Related to #1652 - updates porosity calculation when used with MRF to use relative velocity
Test case from bug report: [rotatingCylinders-test.tgz](/uploads/49641463ba3d523874517a126aa32293/rotatingCylinders-test.tgz)v2212Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/423Two new overset solvers2021-02-19T05:08:31ZSergio FerrarisTwo new overset solversTwo new overset solvers: overInterPhaseChangeDyMFoam and overCompressibleInterDyMFoam and their respective tutorials. A variation of the two simple rotors.Two new overset solvers: overInterPhaseChangeDyMFoam and overCompressibleInterDyMFoam and their respective tutorials. A variation of the two simple rotors.https://develop.openfoam.com/Development/openfoam/-/merge_requests/421WIP: ENH: fixedNormalSlip BC: add 'value' keyword (#1980,#1981)2021-04-15T14:22:30ZKutalmış BerçinWIP: ENH: fixedNormalSlip BC: add 'value' keyword (#1980,#1981)DOC: improve header-file contentDOC: improve header-file contentAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/415Draft: Integration of PDRfitMesh2021-11-10T14:26:44ZMark OLESENDraft: Integration of PDRfitMeshhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/392Draft: Feature ep1364 fan curve clipping2020-12-16T17:13:16ZMark OLESENDraft: Feature ep1364 fan curve clippinghttps://develop.openfoam.com/Development/openfoam/-/merge_requests/390draft: Feature streams2021-04-29T08:25:16ZMark OLESENdraft: Feature streamsAndrew HeatherAndrew Heather