> Looking at it again, from the viewpoint of actual UGRID connectivity data, that does make the 'does X connect to X' question seem a rather abstruse and unimportant.
?? -- but does X connect to Y is the key concept we are trying to capture here. >From the data model perspective, there needs to be SOME way to define the >connectivity. how it's done is a matter of the "encoding", yes? > that basic graph theory is written in terms like these. I'll take your work for it :-) But in "lay" terms, I might say something like: """ The connectivity arrays capture how the individual component of the mesh relate to each other. For example, for the face-face connectivity, each face has N neighbors (where N is the order of the cells, e.g. triangles are N=3). So for each face, the indexes of the three connecting faces is provided, resulting in a num_faces X N array. Note that there is duplication where there is symmetry: that is, if face i connects to face j, face j connects to face i. """ For the most trivial example of a two-triangle mesh, you would have, for the face-face connectivity: ``` [[-1, -1, 1], # face 0 connects only to face 1 [-1, -1, 0], # face 1 connects only to face 0 ] ``` where -1 means "nothing" and the faces are zero indexed. So that those two array entries have dublicative information, representing the symmetry NOTE: I realised as I was writing that that the encoding does not have to be duplicative and symmetric. We tend to store it that way because it's easy to ask the question:"what are the neighbors of face i?" -- but we could only store the connections, which would make it harder to interpret, but easy to encode without duplication. The above two-face mesh would simply be: [[1, 0]] that is: face one connects to face zero. (and therefor face zero connects to face 1 as well) In fact, in UGRID, the "edges" connectivity is described exactly like that. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/153*issuecomment-883550731__;Iw!!G2kpM7uM-TzIFchu!lfKIbGIvZOfhrO6mqfawl6sUjsh9rY0h93P2SjKe2WjT-sCh_-Oh8FGaUW6uAnxaLB6G1Lq7qLE$ This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
