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

particle patches with overlapping extents #269

Open
psychocoderHPC opened this issue Sep 6, 2022 · 5 comments
Open

particle patches with overlapping extents #269

psychocoderHPC opened this issue Sep 6, 2022 · 5 comments
Assignees
Labels
minor change backwards-compatible change question
Milestone

Comments

@psychocoderHPC
Copy link
Member

OpenPMD is defining particle patches https://github.com/openPMD/openPMD-standard/blob/1e1d1fe9fd5914628898ab36fb516c4cfc27eeca/STANDARD.md#sub-group-for-each-particle-species to speedup visualization/checkpointing and other operations.
Particle patches are a spatial region description with a link, defined by numParticles and numParticlesOffset to the large particle data array.
The standard is not defining if it is allowed that the description of a patch (offset and extent) must be unique or if it is allowed that patch description to overlap.

example:

patch 1: offset=3;extent=10;numParticles100;numParticlesOffset=0
patch 2: offset=8;extent=20;numParticles10;numParticlesOffset=100

IMO it is not a problem and very useful but with the restriction that a particle described by numParticles100 and numParticlesOffset can only exist in one patch even if two patches overlap in their spatial description.

Can we clarify this in the standard?

I came up with this during the refactoring of the particle IO in PIConGPU where I like to introduce some kind of load balancing. To be more flexible I would like to linearize my domain to have more possibilities and simpler solutions for the domain decomposition.
If I linearize my domain I will end up with multiple patches overlapping in there spatial description but where each particle is guaranteed to be linked only from one patch.

@psychocoderHPC
Copy link
Member Author

A scatch with 3 particle patches. Patches are overlapping but each particle is only linked from one particle patch.
openPMD-particle_patches

@ax3l
Copy link
Member

ax3l commented Sep 20, 2022

Thanks for raising this. So just to clarify: you ask if the patch constraints allow

  • overlapping patch extents while keeping
  • particles unique to one patch at a time

I think that sounds reasonable and should cause little issues, let me check if the wording needs an update.

@ax3l
Copy link
Member

ax3l commented Sep 20, 2022

Current wording as of 1.1.0:

Patches of particles must be hyperrectangles [...]. The union of all particle patches must correspond to the complete particle's records.

That does not mean it has to be unique, so we are good here. You can do that and it fulfills the standard in openPMD 1.X :) There is also no plan to restrict this in 2.X.

@ax3l ax3l added question and removed enhancement labels Sep 20, 2022
@ax3l ax3l self-assigned this Sep 20, 2022
@ax3l ax3l changed the title particle patches particle patches with overlapping extents Sep 20, 2022
@psychocoderHPC
Copy link
Member Author

Thanks for the answer.

  1. I am voting for an update of the standard where it is explicitly mentioned that particle patches can be overlapping.
  2. optionally. I am voting for restricting the standard and allowing that each particle can only be part of one patch. If multiple patches can link a particle then it is tough to detect particles linked from more than one patch. This is not a problem if particle patches are not overlapping.

@ax3l ax3l added the minor change backwards-compatible change label Sep 20, 2022
@ax3l ax3l added this to the openPMD 2.X milestone Sep 20, 2022
@ax3l
Copy link
Member

ax3l commented Sep 20, 2022

Sounds good, marked for clarification in 2.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
minor change backwards-compatible change question
Projects
Status: Proposed
Development

No branches or pull requests

2 participants