Unique Entities

[termi-official]

No description provided.

[KnutAM]

Sorry, took some time before I had a look, just some thoughts...

• Vertex, Edge, Face: I think these names would make sense to use in Ferrite for what is here called VertexRepresentation etc., since some places we dispatch on the tuple length to infer the entity, which is not very readable.
• Would it make sense to replace the datatypes (e.g. current Vertex) containing Vector{VertexIndex} with a topology struct with a [Ordered]Dict{Vertex, Vector{VertexIndex}}? (either replacing the Matrix for <entity>_<entity>_neighbor in ExclusiveTopology or defining a different topology struct)
• And then adding a topology struct giving information about entities shared with other nodes.

[termi-official]

Sorry, took some time before I had a look, just some thoughts...

* `Vertex`, `Edge`, `Face`: I think these names would make sense to use in Ferrite for what is here called `VertexRepresentation` etc., since some places we dispatch on the tuple length to infer the entity, which is not very readable.

I mean we could rename these, but I designed them this way to differentiate between the pure identifier (*Representation) and the object containing the topology information. See below for more reasoning.

* Would it make sense to replace the datatypes (e.g. current `Vertex`) containing `Vector{VertexIndex}` with a topology struct with a `[Ordered]Dict{Vertex, Vector{VertexIndex}}`? (either replacing the `Matrix` for `<entity>_<entity>_neighbor` in `ExclusiveTopology` or defining a different topology struct)

* And then adding a topology struct giving information about entities shared with other nodes.

We could do this, but for me it does not make sense here. The topology is tightly tied to the distributed mesh data for 2 reasons. First, the mesh itself needs very specific topology information to build up the correct communication patterns (e.g. for distributed Dirichlet elimination) and second, there isn't a single algorithm which works without the distributed topology information. In this light I do not see the advantage of having a separate data type holding the topology information for distributed grids and passing in another argument into the algorithms.

For this reason most of the topology information for the distributed connectivity is directly stored in the shared entities, so we have very direct queries and do not need additional allocations as we would e.g. need when using the topology interface in Ferrite. Hence, for symmetry reasons, I also propose the Vertex, Edge and Face entities, which we could also use within Ferrite, in addition to the representations as tuples.

Does this explain it?