Highlights of the new preCICE release v3.4

News
, , , ,
1

Summary: With preCICE v3.4, we pushed features on several fronts. We made quasi-Newton acceleration bounds-aware as a first step toward fully supporting bounded coupling variables, such as density or volume ratio. Partition-of-unity RBF data mapping can now exploit accelerators, and the geometric multi-scale data mapping supports more variants. Directly install preCICE v3.4.1 to get the latest bugfixes.

DOI: 10.5281/zenodo.19707408
Cite Cite
Release notes of v3.4.0

Bounds-aware quasi-Newton acceleration

Sometimes, coupling variables should be bounded: density must be non-negative, or a volume ratio must be between 0 and 1. Not all data-mapping methods, nor all acceleration methods, directly adhere to such bounds. We have now made quasi-Newton acceleration bound-aware as a first step.

Define bounds together with your data:

<data:scalar name="Density" lower-bound="0" />

And then set a strategy on how to deal with violations in the quasi-Newton acceleration:

<acceleration:IQN-ILS on-bound-violation="scale">
  <data name="Density" mesh="Fluid-Mesh" />
</acceleration:IQN-ILS>

Different strategies are available: scale scales the quasi-Newton step as a whole to fit all violating components into the bounds, clamp cuts the part outside the bounds, discard skips the current quasi-Newton update, and ignore ignores the violation check.

All configuration options

We plan to use the bounds more widely in the future, such as for data mapping or for validating data from the solver.

Accelerator backends for consistent partition-of-unity RBF data mapping

In preCICE v3.2, we already introduced accelerator support for global RBF data mapping via Gingko and Kokkos. Now, we added support for the typically more efficient partition-of-unity RBF data mapping via Kokkos and Kokkos-Kernels as well. The portability of Kokkos is a big plus here: You can now use the data mapping with OpenMP, CUDA, HIP, and SYCL executors. And you can use multiple GPUs combined with MPI. For very large vertex counts (e.g., volume coupling), this is the way to go.

To do so, enable Kokkos-Kernels (and indirectly Kokkos) with the CMake option:

cmake -DPRECICE_FEATURE_KOKKOS_KERNELS_MAPPING=on [...]

And then configure at run time:

<mapping:rbf-pum-direct direction="read" from="Solid-Mesh" to="Fluid-Mesh" constraint="consistent">
 <basis-function:compact-polynomial-c6 support-radius="1.8"/>
 <executor:cuda gpu-device-id="auto"/>
</mapping:rbf-pum-direct>

All configuration options

The data-parallel implementation uses batched solvers. Read more about this approach and its performance in the dissertation of David Schneider (@DavidSCN), Flexible and Efficient Data Mapping for Simulation of Coupled Problems, Section 5.3 (available soon, we will post a link here). We just submitted a compact paper summarizing the results and will keep you posted here as well.

Currently, only consistent RBF data mapping is supported; the conservative variant is under development.

Extended geometric multi-scale data mapping

Even more data-mapping features were added. We also extended the supported geometric multi-scale variants: The axial mapping now additionally supports 1D-2D and 2D-3D cases (in addition to the existing 1D-3D cases).

A 2D-3D example:

<mapping:axial-geometric-multiscale
      direction="read"
      multiscale-dimension="2d-3d"
      multiscale-type="spread"
      multiscale-radius="1.0"
      multiscale-axis="z"
      multiscale-cross-section-profile="parabolic"
      from="Mesh2D" to="Mesh3D"
      constraint="consistent" />

Data from the lower-dimensional participant is distributed over the higher-dimensional interface according to the selected multiscale-cross-section-profile, which defines how the value varies across the interface cross-section. For 1D-3D, we added support for uniform field distributions in this release.

All configuration options

Along with these extensions, we also added tutorial cases: a multi-scale partitioned pipe and water hammer.

Read more in the master’s thesis of Francisco Javier Martínez Quiles.

As usual, there were many more additions, and we also fixed quite a few bugs. Noteworthy ones include a crashing bug in the IQN QR1 filter introduced in v3.2.0, as well as a difficult-to-trigger race condition in the two-level initialization introduced in the initial release of the feature. Full changelog

We also saw quite some external contributions by GSoC applicants, which we appreciate a ton. Thank you! We eventually had to restrict external PRs to avoid losing overview. As the GSoC application deadline has passed, we will soon lift the restriction again.

9 Likes