v2512: New and improved infrastructure

Memory: New PatchField functions avoiding memory allocation

TOP

This enhancement is part of ongoing efforts to improve OpenFOAM performance on modern computing architectures. Memory allocation overhead becomes increasingly significant on contemporary processors where cache efficiency and memory bandwidth are critical performance factors.

First, patch field functions now accept result buffers as arguments rather than returning temporary fields. For example, patchNeighbourField(UList<Type>& result) replaces tmp<Field<Type>> patchNeighbourField().

Second, the internal storage part of GeometricField objects now derives from DynamicField instead of Field to automatically handle storage larger than the addressable size. The additional storage is only allocated once and persists with the field. Its use is to provide a scratchpad to be filled by the API calls, where indexing is now the same for internal values and the obtained boundary values. This comes with near-zero overhead (a single label) when the scratchpad is not used.

These extensions are used in the fused discretisation methods, which avoid most allocations for operations on fvPatchFields and drastically simplify implementing cell-based looping for offloading purposes.

Tutorials

Source code

Merge request

Memory: Memory pool

TOP

As part of the ongoing efforts to support modern architectures, Umpire memory management can be used by the OpenFOAM List and Field containers.

The use of a memory pool is particularly relevant for GPU systems and those with high-bandwidth memory.

When OpenFOAM has been compiled with Umpire, its use can be controlled by the FOAM_MEMORY_POOL environment variable or the memory_pool optimisation switch. Currently, this allows for selection of host, device or managed (unified) memory pools with additional sizing and increment parameters.

The interface to the memory pool is kept opaque, which means it is possible to add memory pool support to an existing installation with only a very minor recompilation (OSspecific) and re-linking (OpenFOAM).

Source code

VTK: Updates to OpenFOAM/VTK infrastructure

TOP

Adjustments to the infrastructure are already underway in anticipation of future support for the new VTKHDF data format. In addition to updates in the parallel infrastructure, e.g., globalOffset, the internal bookkeeping for unstructured (volume) meshes now supports a global addressing space as an alternative to the current stream-based formatting. More is expected to come in future releases as the VTKHDF format continues to evolve as a new standard.