Implement a bounding box calculus

[eschnett]

When handling mesh refinement data, it is often convenient to have utility routines to handle bounding boxes and sets (lists) of bounding boxes.

Each bounding box is defined by a pair (lower, upper) of integer vectors. In this terminology, each chunk that is written is defined by a bounding box, and the overall shape of a mesh is also described by a bounding box. (openPMD sets the lower bound of the mesh always to 0).

I have in mind a generic utility for such operations. This provide three C++ types (point, box, and regions), each handling respective data in D dimensions. These type support operations such as

• union
• intersection
• set difference
• increase size (add ghost zones)
• decrease size (remove ghost zones)
• shift in space
• change resolution (move to coarser/finer level)

Some of these operations are challenging to implement efficiently when there are thousands of boxes in a bounding box set.

When writing AMR data, these operations are typically not needed, because the AMR infrastructure provides the data in the form that openPMD expects. However, when reading or analysing data, these operations are convenient. They allow e.g.:

• Each box in the file can be quickly check whether it is in the region of interest
• Data in the a can be post-processed (e.g. removing ghost zones)
• Overlaps in boxes can be identified (to determine ghost zones)
• For AMR data, coarse grid data need to be removed where fine grid data exists
• Convergence tests involve comparing data with different resolutions; this requires identifying corresponding regions in the simulation domains

I happen to have such a set of routines, written in C++, and also designed for convenient Python wrappers. (C++ cares about the dimension D for efficiency, Python does not.)

Please let me know if this is of interest. I could then create a strawman pull request.

[ax3l]

Hi Erik,

As bespoken: I think that sounds fantastic and we can totally implement this as utility/helper functionality and ship it. Let's include some (AMR) batteries! :)