Add XGC migration algorithm

[ascheinb]

This is a rough draft implementing XGC's current algorithm for migrating particles. The algorithm looks like this:

1. Bin particles by destination rank. (Currently, there are two extra bins: one at the beginning for particles that stay on their current rank, and one for particles that are removed. I see y'all have something similar already.)
2. Sort the particles by destination rank.
3. MPI_Alltoall to get import info.
4. Transpose particles that are being exported (AoSoA -> AoS).
5. Copy exported particles to a buffer
6. Migrate particles via pairwise match-up. This option can be turned off, but it does improve performance for us.
7. Particles are sent to a buffer if the MPI space is different from the particle space. Otherwise, they are sent directly to the aosoa.
8. Transpose the imported particles back (AoS -> AoSoA).

Questions:

• This doesn't compile yet, but I wanted some feedback like where in the code this would go, naming conventions, style changes etc.
• My transpose function is very simple and relies on everything in the tuple being 8 bytes. I want to generalize this, but deeper understanding of Cabana would probably make that task easier.
• GPU-aware MPI follows a somewhat different logic, does Cabana have a different build or other setting for that being enabled?

[streeve]

This doesn't compile yet, but I wanted some feedback like where in the code this would go, naming conventions, style changes etc.

I think the in-place transpose should be in the DeepCopy or AoSoA file, otherwise looks good on files. On first glance style looks good, but I would replace _XGC with Sorted to differentiate this variant. It's either that or we add a type tag argument for Sorted and Unsorted (we do that quite a bit in the neighbor list interfaces rather than different function naming)

My transpose function is very simple and relies on everything in the tuple being 8 bytes. I want to generalize this, but deeper understanding of Cabana would probably make that task easier.

I agree that generalization would be nice here - the existing Cabana::deep_copy functions would be the place to start. Those cover the out of place copies for direct copies and element-by-element copies

GPU-aware MPI follows a somewhat different logic, does Cabana have a different build or other setting for that being enabled?

We always assume GPU-aware MPI is available or that the user has made the appropriate copies to the host. So currently the execution space has to be compatible with the memory space of the AoSoA. We have discussed adding overloads which pass the execution space separately and does the copies if necessary. Would adding that be sufficient to replace the compile option (at the Cabana level)? I can work on that in a parallel PR if that's the case