Simplify filterParticles Kernel

[ax3l]

Summary

On Summit, generation of this kernel shows compiler issues with nvcc 11.3.109: it compiles without warnings but leads to a segmentation fault at runtime.

The fix for the compiler bug is to implement the trivial lambda that is passed to copyParticles w/o capture: [].

We also add explicit capture to a few other lambdas, to simplify compiler intake complexity.

First commit: wow, this reliably triggereds the compiler bug (invalid device function) in step 1. (see reason below)

This simplifies the kernel generation, which also solves the issue seen with WarpX for this line.

Additional background

Checklist

The proposed changes:

• fix a bug or incorrect behavior in AMReX
• add new capabilities to AMReX
• changes answers in the test suite to more than roundoff level
• are likely to significantly affect the results of downstream AMReX users
• include documentation in the code and/or rst files, if appropriate

[WeiqunZhang]

For CUDA, amrex::IsCallable and std::is_invocable work in device code. They also work in host code if the type is a functor (even if its operator() is device only) or a host and device lambda (i.e., AMREX_GPU_HOST_DEVICE). Unfortunately, they do not work in host code on device lambda (i.e., AMREX_GPU_DEVICE). A device lambda has a type of __nv_dl_wrapper_t on the host. It seems that its operator() can take any types such that amrex::IsCallable and std::is_invocable are always true on them. cuda::std::is_invocable has the same limitation.

The limitation is CUDA only. HIP and SYCL work.

[ax3l]

@jmsexton03 asked on slack

[for amrex::ParallelForRNG] is there a reason to use AMREX_GPU_DEVICE rather than AMREX_GPU_HOST_DEVICE? in terms of consitency, is one of these a better pattern?

@WeiqunZhang was your comment in response to that or did I miss a connection?

[ax3l]

I tried the latest version of this PR with the explicit capture by @AlexanderSinn .
Unfortunately this still fails on Summit with CUDA 11.3

[WeiqunZhang]

I didn't know @jmsexton03's comment on slack. My comment was trying to explain why the first version of this draft PR does not work. It's because if constexpr is always true in that case.

First commit: wow, this now reliably triggers the compiler bug (invalid device function) in step 1.

[ax3l]

THIS FIXES IT!!! (lol)

[WeiqunZhang]

[] or AMREX_GPU_DEVICE?

[ax3l]

no capture: []

[ax3l]

The bug label here stands for: "produces a bug with a third-party compiler" not "is an actual bug in our code".