Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add XGC migration algorithm #637

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Conversation

ascheinb
Copy link
Collaborator

@ascheinb ascheinb commented Jun 4, 2023

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?

@ascheinb ascheinb requested a review from streeve June 4, 2023 15:34
@streeve streeve requested a review from sslattery June 5, 2023 16:21
@streeve streeve added enhancement New feature or request performance labels Jun 5, 2023
@streeve
Copy link
Member

streeve commented Jun 5, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request performance
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants