openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2024-03-27T13:36:51Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/676Function1: added 'lookup' Function12024-03-27T13:36:51ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comFunction1: added 'lookup' Function1### Summary
'lookup' Function1, PatchFunction1
### Details of new models (If applicable)
```
type uniformFixedValue;
uniformValue lookup;
name myVelocity;
```### Summary
'lookup' Function1, PatchFunction1
### Details of new models (If applicable)
```
type uniformFixedValue;
uniformValue lookup;
name myVelocity;
```Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/675Draft: update to internal accounting for finite-area2024-03-28T14:32:47ZMark OLESENDraft: update to internal accounting for finite-areaChanges the internal storage location of finite-area from the polyMesh registry to a dedicated registry.
This allows a clearer separation of field types without name clashes (eg, can now have "U" as a name for an area velocity field). It...Changes the internal storage location of finite-area from the polyMesh registry to a dedicated registry.
This allows a clearer separation of field types without name clashes (eg, can now have "U" as a name for an area velocity field). It is also a prerequisite to supporting multiple finite-area fields in the future.
Example of old locations:
```
0/Us
constant/faMesh
system/faSolution
```
New locations:
```
0/finite-area/Us
constant/finite-area/faMesh
system/finite-area/faSolution
```
The updated locations are handled by the `foamUpgradeFiniteArea` script, which provides a simple and transparent means of managing the upgrading without adding in multiple layers of compatibility handling within the code.v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/673reduced overhead and non-blocking transfers for collated and masterOnly file ...2024-03-19T16:02:23ZMark OLESENreduced overhead and non-blocking transfers for collated and masterOnly file handlingThe aim of these changes is to avoid duplicate copies of character data and improved communication throughput.
The buffering in the output stream are now based on OCharStream instead of OStringStream. This allows full recovery of the st...The aim of these changes is to avoid duplicate copies of character data and improved communication throughput.
The buffering in the output stream are now based on OCharStream instead of OStringStream. This allows full recovery of the streamed characters without additional copies. The character data are _"yielded_" from the streaming buffer to pass on to the backend writers without an intermediate copy into string and copy back out of a string. The full buffer, including unused portions, is transferred to avoid triggering any alloc/free at that point. The char data can then be directly communicated (non-blocking) to the output.
On the receiving end, the size of the character content can be established directly from an MPI_Probe prior to setting up the MPI_Recv/MPI_Irecv. This avoids both the memory overhead of PstreamBuffers (the previous implementation) as well as needing to coordinate between all ranks (the PstreamBuffers has a synchronization point when establishing the buffer sizes as part of the PEX algorithm).
When using a master-only writing (non-collated), now use polling dispatch to write file content when it becomes available.v2406Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/667Draft: ENH: Polyhedral AMR2024-02-22T15:34:38ZKutalmış BerçinDraft: ENH: Polyhedral AMR@Development
Test cases: [MR666-test-cases-22Feb24.zip](/uploads/5d70f346da25f7e66088c5dbd0812eef/MR666-test-cases-22Feb24.zip)@Development
Test cases: [MR666-test-cases-22Feb24.zip](/uploads/5d70f346da25f7e66088c5dbd0812eef/MR666-test-cases-22Feb24.zip)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/643Draft: INT: introduce demand-driven fvSchemes and fvSolution2023-12-12T11:58:15ZMark OLESENDraft: INT: introduce demand-driven fvSchemes and fvSolution- functionality similar to that introduced by openfoam.org
fvSchemes/fvSolution now demand-driven and accessed by their respective
member functions schemes() and solution().
This means that the corresponding system files ...- functionality similar to that introduced by openfoam.org
fvSchemes/fvSolution now demand-driven and accessed by their respective
member functions schemes() and solution().
This means that the corresponding system files are not required upon
construction (which simplifies initialization) and potentially allows
supporting different file locations (TBD).v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/642Draft: ENH: shm: blockLevel through ray-shooting2023-11-23T16:33:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comDraft: ENH: shm: blockLevel through ray-shooting### Summary
shm uses a `blockLevel` specification to close small gaps. This is not really useful for small features which might reside inside a single cell. Also it can quite easily give errors if the geometry is not sufficiently resolv...### Summary
shm uses a `blockLevel` specification to close small gaps. This is not really useful for small features which might reside inside a single cell. Also it can quite easily give errors if the geometry is not sufficiently resolved enough. In this feature we use a similar ray-shooting method as is used for the `gapLevel` refinement - opposite rays are shot from each (candidate) cell centre and if both hit a 'blockLevel' surface it sees if the cell is to be deleted.
The disadvantage of the method is if the gap is much bigger than the refinement level - the cells in the middle of the gap are never seen as candidates and will not get removed.
### Details of new models (If applicable)
v2206 tutorial `mesh/snappyHexMesh/opposite_walls`:
![v2206_slice](/uploads/d7333940e8e86c8f596d3b7fbe94e547/v2206_slice.png)
With this change:
![v2312_slice](/uploads/5300bfae192386a41ac03d7d5b9daf75/v2312_slice.png)
### Risks
(Possible regressions?)
(Changes to user inputs?)Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/629Draft: ENH: improve OpenFOAM I/O for std::vector container2023-09-28T06:54:44ZMark OLESENDraft: ENH: improve OpenFOAM I/O for std::vector container- input: added support (similar to DynamicList)
- output: redirect through UList output, which enables binary etc
- these changes enable support for broadcast and other parallel IO
for std::vector- input: added support (similar to DynamicList)
- output: redirect through UList output, which enables binary etc
- these changes enable support for broadcast and other parallel IO
for std::vectorAndrew HeatherAndrew Heatherhttps://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/556Draft: unsteady adjoint functionality2023-11-23T09:43:22ZVaggelis 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.v2312Vaggelis PapoutsisVaggelis Papoutsishttps://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/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/415Draft: Integration of PDRfitMesh2021-11-10T14:26:44ZMark OLESENDraft: Integration of PDRfitMeshhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/390draft: Feature streams2023-08-29T11:07:00ZMark OLESENdraft: Feature streamsAndrew HeatherAndrew Heather