> 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?
Yes, that is what I was "trying" to say ! > ?? -- but does X connect to Y is the key concept we are trying to capture > here. > in "lay" terms, I might say something like: ... All agreed, absolutely I was just trying to express that I think the two descriptions **_are_** compatible, and in fact basically mean the same thing. I **_think_** the key point is that how UGRID actually organises things (what I termed "encoding") is **_not_** the same terminology in which the CF datamodel description is decribed. So, we do need to be confident that they are _equivalent_, but that also means exploring the rules and constraints which are part of the description (on either side of the fence). If I read correctly what has been said here ... The CF datamodel only states that the connectivity relation must be symmetrical : "If A connects to B, then B connects to A". It also describes such relations only on one "domain axis". My ouststanding concern is that UGRID does define additional information structures (and governing "rules") which the CF 'domain' model has no interest in. (1) Firstly, a UGRID mesh with multiple locations relates to multiple domain-axes in CF That can "work", because any data-variable can only reference **_one_** of them, as described : > we have no use case for two or more topology constructs, each of which > applies to a single unique domain axis, and in fact we have no way of > encoding it, so that case should indeed be excluded. So, the CF 'topology construct' can only be atttached to a single domain axis of a domain. That means that UGRID data which maps to a different mesh location is modelled as belonging to a separate, independent "domain". This seems okay for now, but it means of course that the CF decsription has no concept of the intercoupled nature of the different locations. (2) likewise, the CF description has no place for the cross-location connectivities (like face-edge-connectivity) So, I'm not sure where any of that might become practically relevant, but I'm still a little worried that they aren't really describing the same ideas with the same range of possibilities. -- 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-884008101__;Iw!!G2kpM7uM-TzIFchu!heMcp7OrldjJzmI0l-rXlmXX4p2RCrOo9OpiNkaQZTwht7eRpskqRdQyuPdtJH2KB__v_BpyEc0$ This list forwards relevant notifications from Github. It is distinct from [email protected], 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 [email protected].
