# Highlights of the new preCICE release v3.4
**URL:** https://precice.discourse.group/t/highlights-of-the-new-precice-release-v3-4/2932
**Category:** News
**Tags:** data-mapping, quasi-newton, gpu, geometric-multiscale, acceleration
**Created:** [April 23, 2026, 10:59am UTC](https://precice.discourse.group/t/highlights-of-the-new-precice-release-v3-4/2932 "2026-04-23T10:59:00Z")
**Posts on this page:** 1
**Page:** 1
### Author:  [@uekerman](https://precice.discourse.group/u/uekerman)
#### Post date: [April 23, 2026, 10:59am UTC](https://precice.discourse.group/t/highlights-of-the-new-precice-release-v3-4/2932/1 "2026-04-23T10:59:00Z")
_ **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](https://github.com/precice/precice/releases/tag/v3.4.1) to get the latest bugfixes._
DOI: [10.5281/zenodo.19707408](https://doi.org/10.5281/zenodo.19707408)
[](https://precice.org/fundamentals-literature-guide.html#when-to-cite-what) [](https://doi.org/10.5281/zenodo.19707408)
[Release notes of v3.4.0](https://github.com/precice/precice/releases/tag/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:
```xml
```
And then set a strategy on how to deal with violations in the quasi-Newton acceleration:
```xml
```
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](https://precice.org/configuration-acceleration.html#quasi-newton-schemes)
We plan to use the bounds more widely in the future, such as for data mapping or for validating data from the solver.
[ ](https://www.youtube.com/watch?v=RUYHe_yTToA)
* * *
## 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:
```bash
cmake -DPRECICE_FEATURE_KOKKOS_KERNELS_MAPPING=on [...]
```
And then configure at run time:
```xml
```
[All configuration options](https://precice.org/configuration-mapping.html#execution-backends)
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](https://github.com/precice/precice/pull/2536).
* * *
## 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:
```xml
```
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](https://precice.org/configuration-mapping.html#geometric-multiscale-mapping)
Along with these extensions, we also added tutorial cases: [a multi-scale partitioned pipe](https://precice.org/tutorials-partitioned-pipe-multiscale.html) and [water hammer](https://precice.org/tutorials-water-hammer.html).
Read more in the [master’s thesis of Francisco Javier MartÃnez Quiles](https://mediatum.ub.tum.de/1846501).
* * *
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](https://github.com/precice/precice/blob/v3.4.1/CHANGELOG.md)
We also saw quite some [external contributions by GSoC applicants](https://github.com/precice/precice/pulls?q=is%3Amerged+is%3Apr+label%3AGSoC+), 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.