search

parthenon-hpc-lab / parthenon

Parthenon AMR infrastructure
https://parthenon-hpc-lab.github.io/parthenon/
Other
112 stars 33 forks source link

Formalizing `MeshBlock` partitions for creating `MeshData` #1097

Closed lroberts36 closed 3 months ago

lroberts36 commented 3 months ago

I am putting up this issue as the result of a discussion we had on the 6/6/2024 Parthenon sync call.

In #1092, I cleaned up DataCollection a little bit so that MeshBlockData did not need to be pre-built by hand before creating MeshData objects with GetOrAdd. One thing that I changed was that DataCollection<MeshBlockData>::Add can now take create new MeshBlockData in the collection from either another MeshBlockData (as before) or from a MeshBlock. It was not possible to do something similar for call to DataCollection<MeshData>::Add, since there is no analogy to MeshBlock for MeshData, i.e. MeshBlockData is to MeshBlock as MeshData is to ??????.

Additionally, all block list partitioning is dealt with in DataCollection<MeshData>::GetOrAdd_impl. At least to me, this is a little bit of a strange place to have it conceptually. Also, as it is currently written the only partitioning allowed is to the Mesh::DefaultPackSize().

As a result, it seems like it would be a good thing to create an object BlockPartition (or some better name). A set of these could live in Mesh and DataCollection<MeshData>::Add would work on them as well. It seems like it would be straightforward to address most of the issues brought up in #1003, #959, and #419.

lroberts36 commented 3 months ago

This is also relevant to multigrid, since the current partitioning doesn't work there unless pack_size = -1.

lroberts36 commented 3 months ago

1119 takes a stab at this.