Daniel Arndt

> I looked through the code and it isn't obvious where this needs to be deleted again. We could use `Kokkos::push_finalize_hook`.

Is it conceivable that more than one instance of `SetOrRange` is around at the same time?

Yes, that looks problematic: https://gcc.godbolt.org/z/z9xT6Gnb3. In the end, the dealii module probably shouldn't export any symbols outside the `dealii` namespace from external header files but still export specializations or overloads...

> In other words, what we currently do in [#18482](https://github.com/dealii/dealii/pull/18482) is _convenient_ and I think a good first step that I'd like to merge as is. But in the long...

I'd have a slight preference to first get the `CMake` build system in place so that we could actually compile these module partitions to verify that the exported symbols actually...

> What would happen if someone does both We discussed that in https://github.com/dealii/dealii/issues/18526#issuecomment-2926444430. As long as it's the same symbol, it doesn't matter that we would export some aliases.

Any kind of type erasure makes it hard for the compiler to optimize. Would it be feasible to have a `parallel_for` for every subclass/patch type using a separate execution space...

> Additionally, through recent testing, I've noticed that `Kokkos::View` construction appears relatively slow (about two orders of magnitude slower compared to `cudaMalloc`) . This may limit me from temporarily constructing...

> Each patch's computation is relatively small compared to the internal computation. However, I have many different patch types (inlet, outlet, wall, etc.), forcing me to launch separate kernels for...

We also have `Kokkos::partition_space` that helps you create execution space instances using differenet streams (in case of the Cuda or HIP backend), see https://kokkos.org/kokkos-core-wiki/API/core/spaces/partition_space.html.