Potential new system: MeshDivisions

[GiudGiud]

Reason

in #25883 a User wants to be able to transfer data while respecting an underlying hexagonal grid in two simulations. This is essentially already covered in a "nearest" positions kind of approach but there are some inefficiencies as:

• the nearest position isnt immediately computable from an object coordinate
• our nearest-position search is not great right now (fixable I know, we would need a KD tree search for example, and we have a dumb linear one right now)
• you have to think hard about what the bounding box should be for each process. and the documentation of this could be improved (also fixable)

I would suggest to introduce the Partitions system that would be able to cut the mesh and return from any location the index in the partition. Then we only need to search regions with that same index (or if subapps are matched to a partition, the one subapp with that index). This would replace the bounding box checks in the transfer

Design

A new system that hosts a way to cut the mesh

A few examples of cutting things:

• NearestPositionParitition
• HexagonalLatticePartition
• CartesianLatticePartition
• ExtraElementIDPartition
• SubdomainPartition
• VariableValuesPartition (make a grid in a variable / functor values, partition based on the bins)
• PartitionFromParallelPartitioner (retrieved from parallel paritioning)

New objects using the system

• A Positions object we could create: PartitionCentroidPositions
• A use_partition parameter for generalFieldTransfer
• In the postprocessing (VPPs and spatial UOs for transfer), instead of NearestXXXUO or LayeredXXXUO we can define those concepts with PartitionXXXUO. It would be more general.
• A PartitionsPartitioner that would use a partition defined in the input to repartition the mesh

Impact

• Offer hexagonal lattice (and others) matching in transfers
• Dynamically handle re-partitioning from the input file?
• A way to bring in external partitioners?
  Any other ideas?

[dschwen]

Can you clarify this a bit more? This has nothing to do with Partition_er_s, right? How would a CartesianLatticePartition return a specific "Partition" as opposed to a NearestPositionPartition? I.e. how do you knbow which partion ID to choose?

[GiudGiud]

It could though. You could use the Partition from the Partitions system to re-partition ? With a PartitionPartitioner in the Partitioner system!

[GiudGiud]

A CartesianLattice can have a single indexing as ix * nz * ny + iy * nz + nz . So if there are 2, 1 , 3 bins in X, Y and Z, we have 6 parts to this Lattice partitioning

how do you knbow which partion ID to choose?

from any position you can land the ix, iy, iz index so that would get you the ID for that element

[lindsayad]

My first thought which is not about the functionality of the new system is that unless there's a guaranteed one-to-one mapping from the Partitioner to the Partition then we should rename the latter

[GiudGiud]

guaranteed one-to-one mapping

definitely not that's a non-starter.
Happy to hear suggestions for the name then. My other ideas (from synonym search) dont sound as good

• Cuts
• Splits (already used)
• Parts
• Divisions
• Portions
• Shares
• Anchors (this one would be better for positions than partitions)

[lindsayad]

Bounder is my best initial idea haha

[GiudGiud]

If we have multiple Partitions objects isnt it clear that they are not both parallel partitions?

[lindsayad]

When I think of a partition, I think of a processor ID partition. But I could deal with the Partition name; it's not a "non-starter" for me. I like to go to @friedmud for possibly opinionated answers although he's gotten more and more diplomatic with time. @roystgnr is one who thinks about partitions all the time so would welcome his input on the name

[roystgnr]

If I was writing a user interface from scratch, I'd have gone with "Partitioning" (because to a math geek that's a weird but understandable way to say "Partition", whereas to an HPC geek it's clearer because "Partition" may get used to refer to just a single subset contained in a partition). Then "ParallelPartitioning" or "ProcessorPartitioning" would be the specialization of that which assigns each MPI rank its own set.

But at this point there's probably too many people who think of "Partitioner" being synonymous with parallel partitioning. So what other name can we steal...

I don't like "Cuts"; too overloaded with XFEM and mesh generation stuff. "Parts" too overloaded with engineering stuff.

"Portions" is good. "Shares" and "Divisions" aren't bad.

The math geek in me wants to use "Cover" (an "exact cover" is basically "a partitioning, but the set has a topology!", and a more general cover would be a very useful thing in some search algorithms too). But I don't recall ever hearing that term in an engineering class, so maybe it would be more confusing than helpful?

[GiudGiud]

Once everyone s weighted in here we could poll the best names in #moose on slack?

[lindsayad]

sounds good to me

[YaqiWang]

How about MeshGrid?

[GiudGiud]

I like it

[roystgnr]

The word "grid" always makes me think of a structured Cartesian mesh, perhaps passed through a differentiable map. Using it to name a hexagonal lattice is a bit of a stretch; using it to name a division based on unstructured subdomain ids doesn't feel right at all.

Sectors?

[roystgnr]

Actually, "grid" is so overloaded that if we settle on that I won't whine.

[roystgnr]

Taking notes: my favorite suggestion from the Teams meeting would be "sectioning" (with Sectionings for the input file block, and "section" to refer to one subset within a "sectioning"); it sounded like most others preferred Sections.

[GiudGiud]

From the slack poll, MeshDivisions won.

I m going to add this to a warehouse on Problem for convenience (having an easy pointer to the problem makes life easier)
Realistically we could be able to put this in a warehouse on the Mesh instead (and have it available much sooner). I dont think very many things are stored in warehouses on the mesh yet but maybe I m wrong?

[friedmud]

Divisions isn't bad - but what about Tesselations? Ultimately, the pieces need to fit together to cover the whole area - so it really should form a tesselation!

[GiudGiud]

Doesn't have to cover the whole area.