Refactor ParticleAttrib::scatter()

[aaadelmann]

Refactor ParticleAttrib::scatter() so the “hashed scatter” vs “plain scatter” decision is made on the host before launching the Kokkos kernel.

Purpose

The old code did this inside every particle iteration:

size_t mapped_idx = useHashView ? hash_array(idx) : idx;

useHashView is a runtime boolean captured into the kernel. That means every particle pays for a branch, and the kernel body always mentions hash_array(idx) even when no hash view is used.

The new code splits this into two template instantiations:

scatterImpl<true>(...)
scatterImpl<false>(...)

Inside the kernel it becomes:

size_t mapped_idx = idx;
if constexpr (UseHashView) {
    mapped_idx = hash_array(idx);
}

So for the non-hashed path, the hash-array access is compiled out entirely.

Secondary Purpose

The change also moves the hash extent check out of the kernel implementation wrapper and normalizes the type:

const auto hashExtent = static_cast<decltype(iteration_policy.end())>(hash_array.extent(0));

This avoids the Kokkos 5.2 OpenMP/GCC signed/unsigned warning from comparing iteration_policy.end() with hash_array.extent(0) directly.

Behavioral Impact

The public scatter API does not change.

Expected behavior stays the same:

• no hash array: mapped_idx = idx
• hash array present: mapped_idx = hash_array(idx)
• hash array too small for the requested iteration policy: abort with the existing diagnostic

This is mainly a compile-time dispatch/performance/cleanup change:

• removes one per-particle runtime branch
• avoids compiling hash access into the non-hash kernel
• fixes the signed/unsigned comparison warning
• keeps the existing bounds check and scatter semantics

** ToDo

• Test on GPUs, on CPU (MAC) no improvement

• The current cast is probably fine for realistic particle counts, but a more defensive version could use a named policy index type and possibly check representability before casting. For IPPL’s current usage, this is not a practicaxl concern.

[aliemen]

That's actually a nice solution: you now use a template to decide which scatter to use, allowing the compiler to optimize the ternary operation.

However, "on CPU (MAC) no improvement" is to be expected: one conditional statement is (in my opinion) negligible compared to the scatter kernel itself. It's even possible that right now it uses branch predictions, which would leading to no performance difference at all.

When I implemented it, I didn't want code duplication or change templates inside IPPL and settled for a "non-divergent" ternary. But this is for sure the best solution. If you want, I can test this branch against OPALX.

[aaadelmann]

I am now evaluating the performance on LUMI, so no need to OPALX at the moment, thanks Alex !

[biddisco]

I would not expect this to make a big difference because the cost of the branch is really only bad if some of the threads take one path, and some the other - in this case, all take the same path, so it's just an extra compare and jump - however, from an aesthetic point of view, I'd be in favour of templating the kernel as you have done.