Dear Jonathan, Thanks. It sounds like we agree that the domain could have multiple topologies (as opposed to topology _constructs_). It's a good point that 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.
I think that it is important to keep the general definition of a domain topology, that could span multiple dimensions, and to note that a domain could have more than one domain topology, even though we only allow one 1-D domain topology construct to be provided. In this way the land-sea example makes sense. Here's a new attempt. New text in italics, and I'm trying out "domain topology " for size: ### Domain topology construct A domain topology describes the connectivity of domain cells indexed by a subset of the domain axis constructs. When two cells are connected, operations on the data stored on them may be assumed to be continuous across their common boundary. A domain topology construct describes logically and explicitly the domain topology of cells indexed by a single domain axis construct. A domain topology construct contains a connectivity array that spans a _single_ domain axis construct with the addition of an extra dimension of the same size, such that each dimension indexes the cells. The array is symmetrical, and each element indicates whether the pair of cells to which its indices refer are connected. _A domain construct may contain at most one domain topology construct._ _For any subset of the domain axis constructs, excluding a domain axis construct for which there is a domain topology construct, there is an implicit domain topology that is defined by a function of the physical contiguousness of the cells, and/or the nature of the real world or simulated processes that produced the data_. For example, in a field which contains both land and ocean cells, connections between land and ocean cells might be excluded for some physical processes.The description of such an implicit network topology may require metadata that is external to CF. In CF-netCDF a network topology can only be provided for a domain defined by a UGRID mesh topology variable. In this case, the connectivity array is supplied by a UGRID connectivity variable (such as a "face_face_connectivity" variable). -- 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-881458967__;Iw!!G2kpM7uM-TzIFchu!h2xPz5wtNOz0oT71-_LZ1uiYnV1MVBYk3APM9vGqM4uF4gBOl5Ckl_JAHQJlYiG_i-ZqFI9mOb4$ 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].
