PIConGPU domain definitions

You are here: Home > Developer Documentation > PIConGPU domain definitions

---

Current naming scheme

This page describes the internal naming scheme for domain and window offsets and sizes in PIConGPU as described in this issue.

Domains in PIConGPU are always for grid-based quantities and are due to that measured in number of cells.

Selections

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

Selection members

member	type	notes
.size	uint	size of a Selection
.offset	int	offset of a Selection to its next higher hierarchy

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

Naming 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

Resulting semantics

• 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.

Moving Window

PIConGPU uses a moving window when started with the -m command line parameter. It enables simulations that use a moving laser pulse to focus on the pulse for an infinite amount of timesteps while using a fixed simulation grid size. The moving window selects only a subvolume (in y-direction) of the complete global domain for simulation (the y-size of one GPU is subtracted).

After the slide, the global domain offset is increased by the y-size of one GPU while the global domain size stays constant.

During the simulation, GPUs slide from the top to the bottom of the simulation grid as the moving window progresses. The following image illustrates this behavior:

The moving window is implemented as a Window selection (see Current naming scheme above). Developers can chose to apply algorithms either on the window covered by the moving window or on the window covering complete global domain. In the first case, use MovingWindow::getInstance().getWindow(currentStep) to obtain a window for the current moving window. In the second case, use MovingWindow::getInstance().getDomainAsWindow(currentStep) to obtain a window for the complete global (and local) domain.

Note: For simulations started without -m, the moving window is always equivilant to the global domain.

Precision of offset annotation: for the description of the simulation domain, e.g., in output files, the offset is always a discrete number of cells. Since the cell size is for most solvers and setups <= speed of light * time step the offset will not increase continuously. This is how it our moving window is propagated, if one only considers the hatched area above (e.g., see the HDF5/ADIOS/png plugins):