Hi @ChrisBarker-NOAA, > The whole concept of an "axis" matches orthogonal coordinates of some sort. > (that's kind the definition of orthogonal, yes?). Mapping a Ugrid to the real > world, the real world is 2D (Or 3D, but let's not go there yet) -- and that > 2D world has 2 orthogonal axis -- X, Y, Lat, Long, whatever. So a mesh > represents a 2D space -- but I wouldn't say it has two axes, or a 1-d > discrete axis either, ir is simply something else. Or "axis" means something > different in this context than I think it does.
I hope I can clear this up a bit ... A "discrete axis" in CF is one which does not correspond to a continuous physical quantity, for example, this is the case for an axis that runs over ocean basins or area types, or for a domain axis that indexes a time series at scattered points. This also applies to the axis that stores the nodes of a UGRID mesh. In many of these cases the discrete axis is sampling a higher dimensional space, as you say. This where the "discrete sampling geometries" of chapter 9 get their name (I always imagine a ship sailing along a sinuous course and recording SSTs at various time intervals). A domain that has such a discrete domain axis construct can also have other domain axis contructs (such as ones for time, level, etc.) which are indeed orthogonal to each other and to the discrete axis. > That means there could be separate definitions, or data variables could share > the same one, yes? If, for instance, multiple variables in the same file are > on the same mesh, they share a single domain definition, yes? Yes. Ish. Say we have two data variables in a file (temperature and precipitation, say) that are both defined on the faces of the same mesh. The CF data model currently views all field constructs (i.e. data variables in this context) as independent entities, so each of the resulting two field constructs would contain its own domain, and those domains can only, in the data model world, be seen to be equal by inspection. This is different to the [ISO 19123 coverage model](https://urldefense.us/v3/__https://www.iso.org/obp/ui/*iso:std:iso:19123:ed-1:v1:en__;Iw!!G2kpM7uM-TzIFchu!mKc8eKpI4oK_LVEInhm9uLhMqlotAzTZUKB3NH_XFq73vfIuwCvkKsmkysbNhqFoCYv7fWY7bT0$ ) that allows for multiple "features" (i.e. data variables) to be defined at common locations (this is discussed [section 5.1 of the CF data model GMD paper](https://urldefense.us/v3/__https://gmd.copernicus.org/articles/10/4619/2017/gmd-10-4619-2017.pdf__;!!G2kpM7uM-TzIFchu!mKc8eKpI4oK_LVEInhm9uLhMqlotAzTZUKB3NH_XFq73vfIuwCvkKsmkysbNhqFoCYv7lNzAYhM$ )). CF has always had this feature (problem?), even with traditionally defined domains. We're back in SGRID territory here - and one day the CF conventions will formalise domain sharing and linked domains, but until then we're stuck with this theoretical independence. I don't think that this is in any way a blocker for the integration of UGRID into CF, though. Your software can explicitly share domains in the ISO 19123 vein if it wants to. > That makes sense but the language I first noticed said a "symmetric array" -- > I think we need to be careful about the abstraction of a symmetric matrix and > the realization of an "array" in code, or a netcdf file, or ... And it needs > to be clear that it's a abstract (sparse) boolean matrix, rather than an > actual array (necessarily). I hear you, but would like to keep "array", as that is used in the same context throughout the data model description. I think we can improve things by explicitly noting the difference between logical representation and encoding in the text (changes in **bold**, I've also made a few other changes mentioned above). How's this? ### 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. **The connectivity of a cell to itself is undefined, so the diagonal elements of this array are ignored**. 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 **domain** 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. **Unlike the domain topology construct's connectivity array, a UGRID connectivity variable's data is not stored as a symmetric matrix that indicates the connectivity between any two cells. Instead, the trailing dimension of a UGRID connectivity variable's data records, for each cell, the indices of the other cells to which it is connected (padded with missing data if the cell has fewer connections than some others).** > Thanks for taking the time to educate me! Then it's very much a two-way street! David -- 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-888189611__;Iw!!G2kpM7uM-TzIFchu!mKc8eKpI4oK_LVEInhm9uLhMqlotAzTZUKB3NH_XFq73vfIuwCvkKsmkysbNhqFoCYv7gLVIrf4$ 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].
