Naming global/local/total offset

[ax3l]

We have to make namings within PIConGPU more consistent.

So far we used:

• local offset: a cells position to the zero point within the same GPU (local size: domain on this GPU)
• global offset: the same offset + the offset regarding "all GPUs" (local size: domain on all GPUs)
• total offset: global offset + offset due to sliding window

I just made the name "total" offset up. maybe we can find more useful (but significant and short!) names.

@Heikman @PrometheusPi what do you propose?

P.S.: Not related: We used an slightly different scheme in libSplash since it lives somewhere between hdf5-speech and ours.
https://github.com/ComputationalRadiationPhysics/libSplash/blob/dev/doc/manual/UserManual.pdf?raw=true (chapter 3 / page 9)

@f-schmitt-zih Its like this, am I right?

• local: on the same GPU (like PIConGPU) but localOffset describes the offset of this local GPU domain to the global (data complete) domain
• global offset: offset of the all-GPU domain due to sliding window (and globalSize is the all-GPU domain size)

Actually I like the libSplash notion a bit more since it is more consistent. It of course lacks the "PIConGPU local offset" since it does not need it.

---

Of course it is always the question if the "next" locality should include or exclude the one before, but I think exclusive (e.g. a GPU-cell-number is between [0;GPU-cell-size) and not in the range [GPUoffset + slideoffset; same+size)) is quite useful since most of the operations will need less precision and queries.

[f-schmitt]

I like the idea of renaming those offsets, I was thinking about that myself recently when working on the parallel I/O restart. We don't need to create especially short names, this is not the 70's anymore. It's much more important to make them clear and significant.

How about ?

• local offset: local to the data of this GPU ((local size: domain on this GPU)
• global/simulation offset: offset to the start of the current computation, i.e. moving window, since it is the part that is currently simulated
• physical offset: offset to the start of the physical domain that is simulated over all iteration

Your notion of libSplash naming scheme is correct!
I agree that domains/offsets should be exclusive (even though this is not the case in libSplash, but we can just add both if necessary)

[ax3l]

I think putting the influence of the moving window in the physical offset instead of the global offset is more useful.

the question for sliding window is also: how to refer to the offset slide + virtual window offset? (maybe that is the thing you were talking about in point 2?). because it is a difference between the total data offset due to re-hanged GPUs and the continuous motion of the virtual window.

I do not like the name "physical" offset sooo much, any other ideas?
Names do not need to be extraordinary short, but type-able (isIsNotTheJava90sAnymoreEither) :)

Let us us add a svg to this thread to describe the notion in the draft phase.

[f-schmitt]

how about renaming localDomainOffset to movingWindowOffset since it only matters with the moving window

[f-schmitt]

Draft of our definitions

participants: @f-schmitt-zih @psychocoderHPC @ax3l

objects

• domain = contiguous volume on one or all GPUs
• window = any part of a domain

object attributes

attribute	type	notes
.size	uint	size of an object
.offset	int	offset of an object to its next higher hierarchy

• offsets are exclusive and always relative to the element that is above it in the hierarchy

hierarchy

• local = the object is located on the current ("my") GPU, no guards
• global = the currently simulated volume over all GPUs, no guards
• total = takes parts into account that are not in the global volume, e.g. previous areas that have been gone due to the sliding window

---

this results in

• global:
  • globalDomain.size = size of currently simulation volume on all GPUs
  • globalDomain.offset = offset caused due to slides: offset to the totalDomain
  • globalWindow.size = size of the current/selected moving window (cutting away areas of the globalDomain that are before/after the window)
  • globalWindow.offset = offset of moving window from the first GPU: offset to the globalDomain
• local:
  • localDomain.size = size of my GPU
  • localDomain.offset = beginning of my local domain in the global Domain
  • localWindow.size = size of the volume of the moving window on my GPU
  • localWindow.offset = offset of my moving window part from the start of the global window

---

Special use cases

• My GPU is not contained in the moving window.
  • localWindow.size == 0
  • localWindow.offset == undefined
• An interface, lets say the gasProfiles, may needs an inclusive domain offset like
  • localDomain.offset+globalDomain.offset (1)
  • how to name the result (1) in the interface?
  • suggestion: localDomainToTotal = (1)
  • note: usually, as defined above, localDomain means localDomainToGlobal because global is the next higher hierarchy.

[f-schmitt]

[f-schmitt]

@ComputationalRadiationPhysics/picongpu-maintainers
No new comments in 5 days ... I guess this is a common agreement?

[PrometheusPi]

👍

[ax3l]

👍

[f-schmitt]

I updated the wiki with our new definitions. Feel free to correct or clarify anything if necessary.

[ax3l]

Ah that's excellent.
It might be useful to get it a bit closer to the proposed implementation in #403. E.g. the word object could be replaced with Selection.