Add segmented array type

[MarcelKoch]

This PR adds a class to store a segmented array. A flat ginkgo array is partitioned into multiple segments by an additional index offset array. The segment i starts within the flat buffer at index offsets[i], and ends (exclusively) at index offsets[i + 1]. The class only provides access to the flat buffer and the offsets.

Used in: #1543

PR Stack:

• Add segmented array type #1545
• Distributed Index Map #1543
• Adds Index map device kernels #1579
• Use index_map in distributed::matrix #1544
• Add specific communicator for neighborhood communication #1588
• Adds distributed row gatherer #1589

---

Old Description

This PR adds a type collection::array which is a std::vector like class that stores multiple arrays. These arrays are all subviews of a shared buffer.

I think technically this could be considered as a batch::array, but I'm not sure if we want to go that way. As a batch::array this would interleave the dependencies between the batched and non-batched stuff, and I'm not sure if that is a good idea.

[upsj]

Do you actually need these individual sub-ranges to be materialized as array views? Because otherwise this is just the typical row_ptr - col_idxs structure, and we might be better served with a fully functional std::span replacement and a range-of-ranges interface

[MarcelKoch]

At least for CPU kernels the arrays are quite handy. But you're right, something like std::span would be better suited.

[upsj]

I've had it in my mind to provide a nice abstraction over these segmented arrays (including range-for support) for a while already, if you want I can resurrect my prototype code

[MarcelKoch]

Sure, if it's not too much work, we could use that. I can also take that over if you want.

[sonarcloud]

Quality Gate passed

Issues
6 New issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[MarcelKoch]

@upsj maybe this could be formulated using ranges and accessors. Accessing the segmented array could be thought of as [i][j], where i is the array index, and j the index within the array. But I don't know enough of ranges and accessor to judge if that would be appropriate.

I don't think that is a good abstraction, since the size per dimension isn't constant.

[upsj]

I think this is a useful construct, I would try to make it more generic in some contexts (index type) and more restricted in others (host-accessibility). I would imagine a device adapter based on what I implemented as segmented_range in #1582 might be useful here.

Also we would need some tests and documentation before we can merge this

[upsj]

I think I would call this a segmented array, since the corresponding operations are referred to a segmented sort/reduction/... in papers and the cub library. That would also avoid the need for a separate namespace

[upsj]

I think this design might encourage poor performance - it invites using a kernel invocation for each MPI rank, which might scale poorly. Instead I would try to do this with a single kernel for all ranks, and a corresponding device view.

[upsj]

Considering #430, I would prefer if we used int64 or even a generic integer type.

[pratikvn]

I agree with Tobias that calling it segmented_array would be better. Otherwise, I dont have any other concerns.

[upsj]

LGTM mostly, does it need to be part of the public interface, or can we put it in detail first? I believe it might change significantly with segmented ranges.

[MarcelKoch]

@upsj I don't think this will change with the segmented ranges at all. The ranges are only relevant on the backend side. The index_map has this type as constructor parameter, and accessors to it, so I would not put it into the detail namespace.

[pratikvn]

Maybe also update the PR name ?

[pratikvn]

Mostly looks good. Just one question regarding the _const_x naming for const getters.

[pratikvn]

You can move this directly within the class, right ?

[MarcelKoch]

I can actually move them into the .cpp. I did that, but I won't wait for the full CI pipeline to merge it.