You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#250 adds the edge_node_connectivity to the from_meshkernel constructor. Meshkernel also provides an edge_face_connectivity now: Deltares/MeshKernelPy#82
There's no way to use it right now, since Ugrid2d.__init__ takes no edge_face / face_edge argument. However, a relevant question is also whether it's necessary, since xugrid will derive these optional connectivities itself. As an overview (something like this should probably go in some form of developer docs...):
face_edge / edge_face connectivities are optional, and can be derived.
the edge_node_connectivity is also optional, but implicitly a choice is made: what is the ordering of the edges? Xugrid currently uses np.unique, which sorts to find the unique values. Hence, the ordering of the xugrid edges depends on the node index (i.e. edge with nodes 0 -> 1 will always be the first edge).
A different program may have a different ordering of edges (e.g. could be sorted on x-y coords); it may be arbitrary. This doesn't really matter, as long as no edge associated data is present. E.g. flows on the edges very clearly have a location on the grid, and they shouldn't be freely shuffled around.
Xugrid finds the edge_node_connectivity by sorting; the inverse permutation also directly derives the face_edge_connectivity. Hence the single edge_connectivity function will always return both.
In case a prior edge_node_connectivity exists (so the order matters!), we do more sorting to maintain order and the identity of the edges.
In xugrid, the edge_face_connectivity is derived by simply inverting the face_edge_connectivity.
When face_node_connectivity and edge_node_connectivity are given, the identity/order of the faces and the edges are both fixed.
This should mean that face_edge_connectivity (and edge_face_connectivity) are fully determined, except for the order in the rows.
E.g. the following edge_face_connectivities are equivalent:
0 1
1 2
2 3
versus
1 0
1 2
3 2
The UGRID conventions do not specify the row order (you could let the normal point to the first face, and the antinormal to the second face or something, but this isn't part of the spec and doesn't seem very useful either).
So, it should be easy to check:
Get a xugrid.Ugrid2d object from meshkernel, with edge_node_connectivity for a couple of topologies
Get the associated edge_face_connectivity from meshkernel, reshape to (-1, 2)
Run sort(..., axis=1) on both
Compare whether they are identical
If my reasoning is correct, they should be identical (after sorting within a row). In that case, we don't have to complicate the constructor and internal logic any further, and rely on xugrid to provide the edge_face_connectivity as needed.
The text was updated successfully, but these errors were encountered:
#250 adds the edge_node_connectivity to the
from_meshkernel
constructor. Meshkernel also provides an edge_face_connectivity now: Deltares/MeshKernelPy#82There's no way to use it right now, since
Ugrid2d.__init__
takes no edge_face / face_edge argument. However, a relevant question is also whether it's necessary, since xugrid will derive these optional connectivities itself. As an overview (something like this should probably go in some form of developer docs...):np.unique
, which sorts to find the unique values. Hence, the ordering of the xugrid edges depends on the node index (i.e. edge with nodes 0 -> 1 will always be the first edge).edge_connectivity
function will always return both.E.g. the following edge_face_connectivities are equivalent:
The UGRID conventions do not specify the row order (you could let the normal point to the first face, and the antinormal to the second face or something, but this isn't part of the spec and doesn't seem very useful either).
So, it should be easy to check:
If my reasoning is correct, they should be identical (after sorting within a row). In that case, we don't have to complicate the constructor and internal logic any further, and rely on xugrid to provide the edge_face_connectivity as needed.
The text was updated successfully, but these errors were encountered: