i.e. thetao[time, depth, j, i] where i and j are logical dimensions • Represent cell center coordinates as lon[j, i], lat[j, i] • Represent cell vertex coordinates lon[jm, im], lat[jm, im] The size of these arrays is usually just 1 element longer in each dimension (or can be the same e.g. for periodic domains)
geometry of the mesh and does not take advantage of the inherent contiguity of the cells • It requires data providers to take an extra step to generate cell boundaries (many don’t and simply ignore CF conventions) • It requires visualization software to decode boundaries back to contiguous mesh (possible errors / inconsistencies here) • It’s a waste of memory
representation of native mesh coordinates in CF. • While we’re at it, can we also deal with concepts such as “cell center variable,” “cell face variable,” etc.? • None of this needs replace the existing “cell boundaries” convention.
a structured staggered grid without trying to capture the details of ﬁnite element formulations” http://sgrid.github.io/sgrid/ • Many of the technical issues have been thought through already. • Can CF formally incorporate / reference SGRID?
What is the governance of SGRID? How can the community propose changes / updates? • How do we describe periodic (i.e. “wraparound”) dimensions? Does this matter? • What about cubed-sphere type multi-faceted grids?