> I am now quite troubled by the use nsigma, though! How it is applied is > surely dependent on whether one assumes one-based or zero-base indices k, as > @JonathanGregory pointed out. And the possibility of it becoming incorrect > when the vertical dimension is subsetted is not good. These problems all > disappear, I think, if we insist on missing values for the out-of-range > portions of zlev and sigma...
Quite right. I had to sketch this to convince myself. See below. Having vectors `sigma` and `zlevel` both dimensioned on `nlayers` with each undefined when they are out of scope makes the conversion unambiguous. In my diagram, it doesn't matter in which order (top to bottom, or bottom to top) the values are stored, and whether index k is 0-based or 1-based is at the discretion of whoever reads the file. Here, the square symbols with the dot are the nominal layer (cell) centers for a typical vertical staggered grid where tracers are defined at the cell centers, and vertical velocity (w) at the layer interfaces dimensioned nlayers+1. To get z of layer interfaces we use the same equation but need a second vector of `sigma_w` values (here 6 defined values -1:0.2:0). **The sigma_w = -1 has to be defined.** If there is a counterpart `zlevel_w` vector then the interface corresponding with c_depth has to be **undefined**. If the layers _are not uniform thickness_ one can't infer `zlevel_w` from the center depths `zlevel`. This is a common failing of z-level model output files that don't provide layer thickness data. It confounds computing vertical integrals from -h to eta. For the sigma-space the layer thicknesses are readily computed by differencing the z on the interfaces computed with sigma_w.  -- 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/314*issuecomment-825206885__;Iw!!G2kpM7uM-TzIFchu!nFs_AWLg7cO4s7_O0I03uYz-eti4v6zBUmPNaUFD6JzOVv-s7GnGbF8EM6IdvrW5p91ixUQc-2U$ 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].
