Standard names: *ocean model grid information*

[jmecki]

Before submitting an issue be sure you have read and understood the rules for vocabulary changes and review the guidance for constructing standard names

Please note that it is fine to group together a number of proposals in a single GitHub issue (i.e. it is not necessary to open a separate issue for each vocabulary term). Change proposals should include the following information as applicable.

Proposer's name
Jenny Mecking

Date
Sept. 8 2024

For each term please try to give the following:

- Term
eastward_ocean_gridbox_length_at _t_point

- Description
The length of the gridbox in the east/west direction for the t-point gridbox

- Units (If applicable).
m

- Term
northward_ocean_gridbox_length_at _t_point

- Description
The length of the gridbox in the north/south direction for the t-point gridbox (i.e dy on t-points)

- Units (If applicable).
m

- Term
eastward_ocean_gridbox_length_at _u_point

- Description
The length of the gridbox in the east/west direction for the u-point gridbox

- Units (If applicable).
m

- Term
northward_ocean_gridbox_length_at _u_point

- Description
The length of the gridbox in the north/south direction for the t-point gridbox (i.e dy on u-points)

- Units (If applicable).
m

- Term
eastward_ocean_gridbox_length_at _v_point

- Description
The length of the gridbox in the east/west direction for the v-point gridbox

- Units (If applicable).
m

- Term
northward_ocean_gridbox_length_at _v_point

- Description
The length of the gridbox in the north/south direction for the t-point gridbox (i.e dy on v-points)

- Units (If applicable).
m

[github-actions]

Thank you for your proposal. These terms will be added to the cfeditor (http://cfeditor.ceda.ac.uk/proposals/1) shortly. Your proposal will then be reviewed and commented on by the community and Standard Names moderator.

[JonathanGregory]

Dear Jenny @jmecki

It is interesting that standard names haven't previously been defined for the horizontal size of gridcells. Usually this information is not necessary to store as a data variable, because you can calculate it when needed from the bounds of the latitude and longitude coordinate variables. Please could you describe why these standard names are needed?

Best wishes and thanks

Jonathan

[ChrisBarker-NOAA]

I'd note also that these would only apply for north-east aligned rectangular grids.

maybe there's a more general standard name that could be used?

[jmecki]

Thank you for your responses, it's the first time I've proposed variable names so I might have missed something when I looked things up.

In response to Jonathan's comment, while you can compute it from the latitude and longitude (bounds/vertices) models often artificially narrow channels, for example the Strait of Gibraltar and in the Indonesian Throughflow region. This is especially true for models that have ocean model resolution similar to the models used in CMIP6 (i.e. 1 degree), therefore giving incorrect values.

In response to Chris Barker's comment, what I had in mind were the lengths/widths of the grid boxes which if they are on an irregular grid then they wouldn't be strictly northward or eastward but along the model grid lines.

Maybe the names:
ocean_gridbox_length_at _t_point
ocean_gridbox_width_at _t_point
ocean_gridbox_length_at _u_point
ocean_gridbox_width_at _u_point
ocean_gridbox_length_at _v_point
ocean_gridbox_width_at _v_point

However, how length and width are defined might be unclear.

[ChrisBarker-NOAA]

models often artificially narrow channels

very interesting -- I had no idea. So yes, this does make sense to me as something to capture in a standard_name

Is "gridbox" the correct term, however? though I have idea what a bette tem might be:

channel_width? or some such?

However, how length and width are defined might be unclear.

yes, that's a trick -- "x" and "y" -- I can't recall if those terms are currently used to mean "logical x [y]" rather than literal.

[atreguier]

The convention so far in standard names is to use x and y, e.g., "ocean_heat_x_transport: "x" indicates a vector component along the grid x-axis, positive with increasing x"

[ChrisBarker-NOAA]

thanks @atreguier -- then "x" and "y" do seem to mean the correct thing in this context.

[martinjuckes]

Could this information be provided using the mesh topology attributes defined in Appendix K of the CF conventions?

[JonathanGregory]

Dear Jenny

I'm a bit puzzled. In answer to my question above you agreed you can get gridcell dimensions from the cell bounds, but you say that these are not necessarily the "right" answers. Surely they are the true answers for the grid, even if not for reality. Is it perhaps not the gridcell dimensions that you want to record and give standard names to, but the real distances across straits etc?

Best wishes

Jonathan

[taylor13]

Hi Jenny,

I would find it helpful if you could describe how a model actually treats the processes in these "special" grid cells where somehow the equations governing the ocean are modified to take into account a channel that is narrower than the what the cell can represent. Is there a reference for how they are treated?

thanks,
Karl

[atreguier]

Dear Karl, dear Jenny,
I know that adjusting the width of a one-grid-point-wide strait (narrowing it to reduce the volume flux) was done often in the NEMO model. It may be referenced in the manual, I am not sure. Even when no "ad hoc" modification has been made, in NEMO the "scale factors" (the dx,dy, used in the disctretized equations) are not exactly the distances between grid points (to machine accuracy) because they are computed analytically from the equations describing the grid. So, in order to close the mass budgets, we need to use the original "scale factors" of the model. I do not know how it is for other models, especially fine volume models with triangular meshes. It would certainly be interesting for modelling groups to publish on esgf everything a user needs to compute budgets.

[jmecki]

Thank you Anne-Marie, I agree with what you are saying and I am also most familiar with NEMO. The variables I'm looking for are basically the equivalent of the NEMO variables 'e1t, e2t, e1u, e2u, etc...' while the e3* variables are a bit easier to estimate (I also opened the issue 220 for these). Not having this specifically has lead to difficulties in estimating transports in models. I think just having widths of channels will not be sufficient because the channels with artificial narrowing might end up being different in different models and resolutions. I tried estimating the grid box dx/e1* and dy/e2* (lengths and widths) from the information provided in the CMIP5 and CMIP6 database at T,U and V points and have found that several models have had this issue but mainly the NEMO based ones.

[github-actions]

This issue has had no activity in the last 30 days. Accordingly:

• If you proposed this issue or have contributed to the
  discussion, please reply to any outstanding concerns.
• If there has been little or no discussion, please comment
  on this issue, to assist with reaching a decision.
• If the proposal seems to have come to a consensus, please
  wait for the moderators to take the next steps towards
  acceptance.

Standard name moderators are also reminded to review @feggleton @japamment @efisher008

[jmecki]

Has there been a decision made about having a name for this? It would be useful to have one even if all models might not be able to provide this field.

Would a possible suggestion now be:

ocean_gridbox_x_length_at _t_point
ocean_gridbox_y_length_at _t_point
ocean_gridbox_x_length_at _u_point
ocean_gridbox_y_length_at _u_point
ocean_gridbox_x_length_at _v_point
ocean_gridbox_y_length_at _v_point

[JonathanGregory]

Dear Jenny

Speaking for myself, I don't think it's yet clear what these quantities actually are. Please could you describe them in geophysical terms, as we need for standard names? How do you use them in a calculation, for example? That might clarify the issue. I think that "gridbox lengths" would generally be understood as the distance between coordinates, as I interpreted it before.

Also, I don't think we would mention T, U and V points in standard names. CF doesn't have a notion of grid arrangements, to which that refers. (Maybe it should, as has been discussed a few times, but that's not the issue here.) I think we need to give a name to a distance needed for some purpose; the gridpoints it applies to should be obvious from the coordinates or bounds.

Please don't give up. These discussions are often difficult, but usually achieve a good result!

Best wishes

Jonathan

[fmassonn]

Hi,

I agree that having these terms would be great to recompute fluxes, or to compute fluxes over non-standard straits.

François

[taylor13]

I'm trying to understand how your model handles a single grid cell or column of single cells (representing a strait). For a strait separating a northern and southern body of water, are the equations applied there the same as for grid cells elsewhere (but, of course, with no east-west transport)? Or is that grid cell narrowed to the size of the actual strait?

If the equations are applied to a grid cell that is narrower than the nearby cells, then I would say your grid is not a simple latxlon grid, but rather a special 2-d grid which is mostly identical to a latxlon grid except for a few grid cells. You could represent the true grid as described in section 5.2 of the conventions and define the cell shapes following the approach described is section 7.1 under Bounds for 2-D coordinate variables with 4-sided cells. The true area of the grid cell (as represented in the model) could then be calculated using these bounds for 2-D coordinate variables. You wouldn't be able to correctly calculate the grid cell area (which is useful for several purposes) if your longitude bounds as defined in the model formulation are not correctly given everywhere (even for the strait cells).

Of course, I might be misinterpreting how the model handles these special "strait" grid cells. It would seem if it solves the equations assuming the strait cells are narrower than nearby cells, then I would think there would be real problems calculating the vertical exchanges between the ocean and the atmosphere. Are those calculations also performed assuming the cells are narrow? If so, then the land model must have wider than normal cells on either side of the strait. That seems unlikely, so maybe the above is all wrong.

[taylor13]

@Mecki Hi Jenny, Somehow I got an email from you that was, I think, supposed to be posted here, so I've copied it here:

Hi Jonathan and Taylor,

I hope this helps answer some of the questions.

I would use these variables as follows:

To compute the volume transport along a constant line in the y/j direction:

$volTrans(t)=\int_{xmin}^{xmax} \int_{H}^{surface}$

Perhaps something has been lost in the rendering. (width of strait)*(depth of strait) will give you the cross-sectional area (in the x-z plane) spanning the strait (separating a more-or-less northern ocean basin from a southern ocean basin). To get a volume transport you would multiply this by a velocity, but that's missing from your formula.

The following remains unclear to me: Has the velocity reported in model output been calculated by the model on a regular grid and then inflated to account for the fact that the strait is narrower than the grid cell? If that's the case, then I see that you must know what the model assumed to be the true strait width if you want to calculate a volume transport.

[ChrisBarker-NOAA]

I edited the TeX in the post -- I think I got it right, but please do correct it if I misunderstood what it was supposed to be.

But as to the topic -- in some models (ROMS), what is computed is the flux through a gird cell -- though it may be provided in the output as a velocity -- in that case, you'd need to know the cross sectional area of the channel -- and it that doesn't match the area of the cell face, you'd need to know that -- is that what this is for?

[jmecki]

I edited the TeX in the post -- I think I got it right, but please do correct it if I misunderstood what it was supposed to be.

But as to the topic -- in some models (ROMS), what is computed is the flux through a gird cell -- though it may be provided in the output as a velocity -- in that case, you'd need to know the cross sectional area of the channel -- and it that doesn't match the area of the cell face, you'd need to know that -- is that what this is for?

Thanks, I was really struggling with the latex in github and accidentally posted it before it was finished. I will post a more complete response once I have it typed up better.

[jmecki]

Hi All,

Sorry it took me a while to respond.

A simple example for which I would use dx on the v grid points would be to compute the volume transport through a section as follows:

where you would have to compute dx on the v points either from the vertices or the centre points of the grid points of the grid boxes where the computation would differ depending on the Arakara grid used in the model. While this isn't too complex it gets more complex when changing to temperature/heat and salinity/freshwater transports where you have to move all the data (temperature, salinity and velocity) to the same grid point, typically along the grid box edge of the t-points. This again is dependent on the model grid used and having dx, dy and dz on the different grid points (i.e. t,u,v,etc).

In terms of the comment related to ROMS, yes this is something that it would be used for.

Furthermore, as mentioned before if the grid boxes have an artificially narrowed point for some channels, often estimating dx, dy, and dz give the wrong value leading to spikes that shouldn't be there...

In Mecking and Drijfhout 2023 in the methods we made the comment: 'In global and Indo-Pacific computations of OHT there are spikes at the latitudes which are impacted by Indonesian throughflow in some models. Several ocean models which do not have high enough horizontal resolution to resolve the narrow ocean channels, like the ones present in the Indonesian throughflow, artificially narrow these channels but only on either the U- or V-grid points. The information available in the CMIP5/6 archives only contains information about the grid size on the T-grid points. For the models where these spikes occur, we removed the data from the latitudes where the spikes appear.'

While it is possible to compute dx and dy from the grid box vertices this is not always provided and it adds extra computations and may not give the correct values, especially if there are artificially narrows channels. Please correct me if I'm wrong, I'm not a model developer, but from the ocean model code I have looked at, in both Arakawa-B and Arakawa-C grid models they used dx and dy values at the t,u and v grid points in the computations as opposed to the vertices. I believe that it would still be very useful to have names for these variables even if there might be work arounds.

[ChrisBarker-NOAA]

Furthermore, as mentioned before if the grid boxes have an artificially narrowed point for some channels, often estimating dx, dy, and dz give the wrong value leading to spikes that shouldn't be there...

While it is possible to compute dx and dy from the grid box vertices this is not always provided and it adds extra computations and may not give the correct values, especially if there are artificially narrows channels.

I think that "artificially narrows channels" is the key point here -- otherwise, the grid is well defined, and I don't think we need standard names. But if there's been an adjustment in the model, such that you can't compute the correct flux from the grid geometry, then you absolutely need to know the "virtual" channel size.

So I support the idea -- but have no opinion about how to exactly spell the name :-)

[atreguier]

Hi everybody, I just realized that this procedure to artificially narrow some straits is well explained in the NEMO manual , with a nice figure. Here it is
nemo_manual_handmade_grid_corrections.pdf

[JonathanGregory]

Dear Jenni @jmecki et al.

Thanks for explaining. I agree that working out dx and dy on velocity points from the tracer grid is quite intricate, so it's convenient to record them as data variables with metadata to identify them. We can regard dx and dy as metrics of the grid. We already have a standard name for dz, namely cell_thickness. It would be consistent to use standard names of cell_x_width and cell_y_width for dx and dy respectively. The coordinates of the variable containing the quantity show what grid it's on, so that shouldn't be in the standard name. To make the correct variables easier to find, we could define thickness, x_width and y_width as keywords for the cell_measures attribute, which currently supports only area and volume.

However, if straits have effective widths that differ from what the gridpoint coordinates indicate, that's not a metric of the grid, and you can't work them out. I don't exactly understand your equation, because of three appearances of v on the right-hand side. I think we can write the northward volume transport in m3 s-1 through a section at latitude row $j$ as

$$V(j,t) = \sum_{i=\mbox{west}}^{\mbox{east}} \sum_{k=\mbox{surface}}^{\mbox{bottom}} \delta V(i,j,k,t)$$

where

$$\delta V(i,j,k,t) = v(i,j,k,t)\ dx'\ dz$$

is the contribution from gridbox $(i,j,k)$ to the transport, where $dx'$ is the effective width of the cell for transport and $dx'\leq dx$, the cell x-width. Is that right? If so,

$$dx' = \frac{\delta V/dz}{v}$$

This is the ratio of the ocean_volume_y_transport $\delta V$ (an existing standard name, unit m3 s-1) per unit thickness $1/dz$ to sea_water_y_velocity $v$ (an existing standard name, unit m s-1). Hence we could give $dx'$ the standard name ratio_of_ocean_y_transport_per_unit_thickness_to_sea_water_y_velocity. Would that make sense to you?

Best wishes

Jonathan

PS How marvellous that you can write $\TeX$ in markdown. I didn't know that before!

[jmecki]

Hi All, sorry about all the v's in the equation. That's my bad, in my head I think of dx on the v grid points as dxv and similarly dy as dyv and dz as dzv I should have been more precise and defined this. I like Jonathan's suggestion about using
cell_x_width and cell_y_width, that makes it clear for me.

[JonathanGregory]

Yes. CF doesn't have a way to describe Arakawa grid relationships, though it's been mentioned a few times. However, if you provide these cell-length fields as 2D, the user can compute some things, just by using the metric on the appropriate grid, without having to understand Arakawa grids.

[jmecki]

However, if you provide these cell-length fields as 2D, the user can compute some things, just by using the metric on the appropriate grid, without having to understand Arakawa grids.

I agree, making having these variables very handy :)

[japamment]

Dear Jenny, @jmecki

Thank you for your proposals in this issue and for pursuing the discussion.

Thanks also to those who have contributed helpful questions and comments to the discussion @ChrisBarker-NOAA @taylor13 @atreguier @atb299 @martinjuckes @larsbarring and in particular to Jonathan @JonathanGregory for coming up with a formulation for the names that it seems can be agreed.

Since the names themselves seem close to agreement I have summarized them again below and added description text based on the discussion here and existing names.

cell_x_length
Units: m
Description: "Cell" refers to a model grid-cell. "Cell_x_length" is the length of the grid-cell in the x direction of the model grid.

cell_y_length
Units: m
Description: "Cell" refers to a model grid-cell. "Cell_y_length" is the length of the grid-cell in the y direction of the model grid.

cell_x_length_for_velocity
Units: m
Description: "Cell" refers to a model grid-cell. The quantity with standard name cell_x_length_for_velocity is the length of the grid-cell in the x direction of the model grid used to calculate flow in channels that are too narrow to be accurately represented at the horizontal resolution of the grid. The cell_x_length_for_velocity is less than the length that can be calculated directly from the grid coordinates, which has the standard name cell_x_length.

cell_y_length_for_velocity
Units: m
Description: "Cell" refers to a model grid-cell. The quantity with standard name cell_y_length_for_velocity is the length of the grid-cell in the y direction of the model grid used to calculate flow in channels that are too narrow to be accurately represented at the horizontal resolution of the grid. The cell_y_length_for_velocity is less than the length that can be calculated directly from the grid coordinates, which has the standard name cell_y_length.

@jmecki are you okay with these? If so I think they can be accepted for publication now.

Best wishes,
Alison

[ChrisBarker-NOAA]

I'm a bit wary -- have we heard from folks from more that one modeling community?

IIUC, the folks asking for this are from the NEMO, and a similar concept was found in I NorESM. But it's not clear to me that they use them in the same way-- I haven't dug deep, but at the surface, it seems that the NorESM uses this to adjust the model-predicted (and reported?) velocity to get a "true" velocity for determining mixing, etc. which means if you want, e.g. flux, you would use the reported velocity and the standard cell size.

But with NEMO, you could use the reported velocity and this "modified" cell size.

Which may be OK, I suppose the name is the still the same, it's actually the reported velocity that has a different meaning.

Do any other models use this concept? I haven't seen it in ROMS, but I've only looked at the output -- maybe it's used internally, and not reported.

Note: what I see in ROMS output is:

standard_name: sea_water_y_velocity
long_name: v-momentum component
units: meter second-1
time: ocean_time
cell_methods: ocean_time: point

Interesting that it's a velocity (which is how I use it) but the long name is "momentum" -- related, yes, but ???

Anyway, the point is that you need to understand the model to know how to use these parameters anyway :-(.

But if folks think that these terms really does mean the same thing in all (most? some? more than one?) the models that use them, then a standard name makes sense.

NOTE 2:

Perhaps the ship has sailed on this, but I'm uncomfortable with the concept of "grid cell" dimensions -- it makes perfect sense for rectangular grids, but for non rectangular grids (even logically rectangular) not so much:

A 3D (quad) cell is defined by six faces (and 12 edges) -- and the quantity that we're talking about is not the "cell width" but actually the "face width" -- and could (will?) be different for two faces of the same cell.

In fact, in this discussion, we've talked about defining this on the "U points" and "V points", but those are really the U and V faces (or edges, depending on if you are thinking 2D or 3D.

Anyway -- at this point in CF, I don't think the whole edge-face-cell thing is defined (outside of UGRID) -- so maybe stay the course, but we've been warned :-)

[jmecki]

@japamment I am happy with those names, with the comments from @ChrisBarker-NOAA it might be worth noting in the description that they are relevant for rectangular grids. Perhaps slightly changing the wording to 'rectangular model grid' or 'quadrilateral model grid' as opposed to just 'model grid'.

[jmecki]

Hi All,

There has been some offline discussion on this topic between @japamment , @atreguier and I. Below is also sketch to help explain some of the details of the variables being asked for:

Through our offline discussion we have come to the conclusion that the most logical thing would be to have the following names (reference to the sketch above to make it easier to follow):

dxto = cell_x_length
dyto = cell_y_length

dxuo = cell_x_length_for_x_velocity
dyuo = cell_y_length_for_x_velocity

dxvo = cell_x_length_for_y_velocity
dyvo = cell_y_length_for_y_velocity

As pointed out in the previous discussions the full set of these variables are more relevant for C-grid models, with dxto and dyto being most important for B-grid models where it's easier to estimate what is needed for the more detailed computations. Also, in B-grid models dxuo=dxvo, dyvo=dyuo, which is not the case for C-grid models. Having names for these variables means they can be formally defined when they are output/used. However, having names for these variables should not influence whether or not they are included in the list of variables output as part of the CMIP dataset or other any other model study output, that is a discussion that should be happening outside of this one.

The point about the artificial narrowing of some channels has been mentioned several times (see previous discussions for more details). This is something that is often done for the NEMO ocean model in courser resolution simulations like the ones use in CMIP6. In my opinion, this is only a part of the reason to have names for these variables and they are useful regardless of whether or not the model uses artificial narrowing of channels.

[davidhassell]

Hi Jenny - Thank you for the nice picture!

I have a question, that I only thought of having seen the diagram ... A quick search on "units" in this issue shows that the canonical units of these names to be "m". Grids are often defined in (some sort of) "degrees", though. In this case the X length of a grid cell in metres will typically vary at different Y locations through the grid cell - more noticeably at higher latitudes. Is this a problem? Is the value representative of the whole grid cell in some way? If so, then this should perhaps be in the descriptions. Calling it a "cell length" without qualifying what that means in the name seems not so appropriate to me, now. Words like "effective" were being suggested earlier, but I couldn't tell on a quick re-read why they were not considered for the current names.

I am a bit reluctant to restart things which are all but settled, so am happy to leave this if no one picks up on it :)

David

[jmecki]

@davidhassell having the units be in 'm' means they would be similar to the thkcello and areacello variables.

[davidhassell]

Hi Jenny,

OK .., but thickness and area are well defined in units of "m" and "m^2" respectively, meaning that there is only one value and it is unambiguous as to what it represents. The length doesn't enjoy that simplicity, I think.

I'm not suggesting that "m" is an inappropriate unit, just that it could be a bit clearer to users exactly what the value in metres is representing.

[JonathanGregory]

Dear Jenny and David

I think the names Jenny has proposed are fine. The word length is appropriate for a quantity in m, and appears in other standard names. David is right that the grid itself is usually described by latitude and longitude, but these grid metrics will be easier to use if they are given as lengths, so they can be multiplied by velocities. In their descriptions, I think we should advise using the names for velocity only when the more general cell_x_length or cell_y_length is not applicable. I wonder why you need the lengths parallel to the velocities as well as perpendicular - maybe it's for calculating derivatives?

Best wishes

Jonathan

[atb299]

Hi Jonathan,

I wonder why you need the lengths parallel to the velocities as well as perpendicular - maybe it's for calculating derivatives?

As far as I'm aware, you don't - I've seen/heard of channels being artificially narrowed, but never shortened. But the names need to be flexible enough to allow a cell length to be provided for restriction in either the x or y direction.

[ChrisBarker-NOAA]

Sorry to throw too much sand in the works this late in the game, but:

1. Is it "velocity" that's the issue, or "flux"? I think flux may be the better term (closely related as well).

In this case the X length of a grid cell in meters will typically vary at different Y locations through the grid cell

This has bothered me as well -- using "length" of a cell only really makes sense for rectangular cells -- and aside from the distortion that comes from the round earth, there are also logically rectangular quad cells that don't have a clearly defined "length". I think NEMO falls into this category, and certainly ROMS does.

ROMS (A C-grid model), at least, puts the "velocities" on the cell edges -- so what you want is the length of that edge, not the length of the cell itself.

But I don't think that CF yes has the concept of "edges" -- at least outside of UGRID.

[atb299]

Hi Chris,

NEMO (also a C-grid model) provides cell dimensions centered on each point on the grid. There is a cell length, width and thickness for the T, U, V, F and W points. Velocities are on the cell edges, and as you say, it is the lengths of these edges that are required. This is especially true for the (few) niche case where cells have been artificially narrowed, so the cell length cannot be obtained by computing the distance between the corners of the cell.

[ChrisBarker-NOAA]

NEMO (also a C-grid model) provides cell dimensions centered on each point on the grid. There is a cell length, width and thickness for the T, U, V, F and W points. Velocities are on the cell edges, and as you say, it is the lengths of these edges that are required.

which is what confused me -- e.g. there are two U values, on the opposite edges of the cell. Those edges are not necessarily the same length. Is it correct to use the (presumably average) value for the "width" of the overall cell? In practice, cells aren't all that distorted, so it probably doesn't matter, but we should be clear about what a "cell length" really means.

[JonathanGregory]

@jmecki, is there a present use-case for cell_x_length_for_x_velocity and cell_y_length_for_y_velocity? If there is, it would be interesting to know the application, and probably relevant to mention it in their description. If not, maybe we don't need to define those standard names just now. Since we'd have established a pattern, it would be easy to add them if required in future.

@ChrisBarker-NOAA, I suppose that "a cell length for velocity" means a grid metric which is used by a model to do certain calculations e.g. compute fluxes from velocities. It's defined by that use, and it's calculated however would be consistent with the model concerned. It's a model concept, but we have plenty of other such standard names e.g. ones which mention model or refer to concepts like "diffusivity".

[atreguier]

Dear all, what is finally the list of variables that would be created?

Just to verify:
cell_x_length_for_temperature , corresponding to proposed CMIP7 variable: dxto
cell_y_length_for_temperature : dyto
cell_x_length_for_x_velocity : dxuo
cell_x_length_for_y_velocity : dxvo
cell_y_length_for_x_velocity. : dyuo
cell_y_length_for_y_velocity. : dyvo

I am afraid the "temperature" points may have been forgotten in the latest discussions.

Anne Marie

[jmecki]

@atreguier would it be better to use for_tracers instead of for_temperature? Otherwise it might get a bit confusing.

@JonathanGregory these values would be useful to define for consistency. Also, they can be used to compute derivatives (e.g. dT/dx can use dxu on a C-grid)

[JonathanGregory]

Dear Anne Marie and Jenny

Standard names imply that the quantity named is for general purposes if there isn't a qualifier of some sort, meaning the quantity includes everything, or applies under all circumstances, etc. If quantities named as cell_x_length and cell_y_length were provided, and no other cell sizes, you would use those ones for all purposes. My understanding is that the proposal comes from the particular need for a "modified" length for flux calculations for some gridboxes. Therefore I think we need only to provide standard names for cell lengths, needed for particular purposes, which differ from the "usual" ones.

I think the quantity cell_x_length_for_y_velocity should be defined or described in some terms which say what it means, or what its purpose is; for instance, it is the cell width needed for calculations concerned with y-velocity. It shouldn't be defined as the x-size of velocity gridboxes, for instance, although that's probably how it is obtained, because that is specific to the construction of the grid. We do not need standard names to distinguish cell metrics for tracer and velocity grids for general purposes. Both grids can use cell_x_width and cell_y_width, because their coordinates and dimensions will distinguish them.

Is the dxu you need for a derivative on the C-grid the "ordinary" velocity cell x-width, or is it the modified one for narrow channels, which motivated the need for special names?

Best wishes

Jonathan

[atb299]

NEMO (also a C-grid model) provides cell dimensions centered on each point on the grid. There is a cell length, width and thickness for the T, U, V, F and W points. Velocities are on the cell edges, and as you say, it is the lengths of these edges that are required.

which is what confused me -- e.g. there are two U values, on the opposite edges of the cell. Those edges are not necessarily the same length. Is it correct to use the (presumably average) value for the "width" of the overall cell? In practice, cells aren't all that distorted, so it probably doesn't matter, but we should be clear about what a "cell length" really means.

Hi @ChrisBarker-NOAA , its a grid, so the two U values have different indices and, as you say, the cell lengths that correspond to each of these points are not necessarily the same. The For NEMO T(i,j) is equidistant between U(i,j) and U(i-1,j):

[atreguier]

Hi, @JonathanGregory , I did not follow the beginning of the discussion, so I'm not sure how I can help... if more description is needed, where must these descriptions/definitions be submitted?
@jmecki , I agree that cell_x_length_for_tracers is more appealing to the Nemo community (we talk about the "T" points as "tracer" points) but I am afraid this may lead to discussions like "what is a tracer? which tracers? which units"? etc etc. If there is no danger of this happening, then yes, I prefer "tracers" as well.

[jmecki]

@japamment in the description can tracers and/or examples of tracers be added to the description, regardless of if for_tracers or for_temperature is used?

@atreguier I worry the other way around, that people might not understand that for_temperature should also be used for salinity...

[taylor13]

It appears that many of the names propose apply only to specific types of grids, so should the "grid type" be included in the standard name? There may be a problem also defining these in terms of different associated variables (e.g., tracers vs. velocities). It's true that velocities may be calculated on cell interfaces, but values are often reported (for some uses) at the same location as the tracers. So cell_x_length_for_x_velocity would depend on which on which of the two grids were used.

I wonder if the "ugrid"conventions might be a better way to describe more completely the grid structure.

Perhaps for now, we should not try to address the general "grid description" problem and deal with the seemingly special case (see top of this issue) of how to indicate the modified width of some grid cells (in certain models), which is done in an attempt to better represent processes in narrow straights (e.g. vertical mixing that depends on vertical shear in horizontal velocity).

[atreguier]

Hi,

I like to compute quantities in a way consistent with the model code, it is necessary when you want to close budgets. In every model on a C grid, the grid lengths are used in the discretized equations. cell_x_length_for_y_velocity is called "e1v" in NEMO, "dxCv" in Mom6, etc. I have not seen any way to submit those variables on esgf. The grid cells are not exact rectangles. An approximate computation of these lengths (as opposed to taking the ones that were actually used by the model) sometimes results in sizeable errors when, e.g., you re-compute a meridional overturning of a transport across many cells. This happens even if there has not been any local modification of the cell lengths.

If there was a way to submit these grid variables to esgf, I suppose that they would be found useful for ocean analyses of all the models that use rectangular grids. Jenny's proposal of the new variables dxu, dxt, etc has been welcomed positively by the "ocean and sea-ice" CMIP7 data request group.

I am not sure that I understand well the relation between cf names and cmor names. Could there be less cf names than Cmor names? for example: a generic "cell_x_length_for rectangular_grid" that would be used for variables Ofx.dxu, dxv, dxt, and a generic "cell_y_length_for_rectangular_grid" that would be used for variables Ofx.dyu, dyv, dyt?

[JonathanGregory]

Dear Anne Marie, Jenny, Karl, Adam et al.

The purpose of standard names is to distinguish and identify quantities in scientific terms. The description of grids isn't part of the function of standard names; that's done by the coordinates. Therefore I don't think the standard names should include any information referring to Arakawa grids or describing the grid type. For the same kind of reason, for instance, air_temperature always has the same standard name regardless of whether it's on height levels, pressure levels or any other kind of vertical coordinate surface.

This relates to Anne Marie's last question. There is no relationship between CF standard names and CMOR names. Exactly as you say, there are fewer CF standard names than CMOR names. CMOR names correspond to distinct data requests, and involve the choice of grid as well as the scientific quantity in their definition.

I agree that it's important to be able to compute quantities in a way which is consistent with model code. That is why CF provides ways to store areas and volumes of cells, and that's why you want to store and identify the relevant grid lengths. For this purpose, it makes sense to to provide data variables with standard names cell_x_length and cell_y_length, both (y,x) where x and y are the horizontal dimensions, to contain the values actually used by the model for each gridcell to calculate derivatives, fluxes and so on. If there is more than one grid, there will be different cell-length data variables for each grid (e.g. the four grids shown in Adam's diagram).

It is fine to have four variables with the standard name cell_x_length, although they can't have the same netCDF variable name of course if they're in the same file. They can be distinguished by the dimensions or coordinates. That's a bit laborious, however. If it's useful, we could add a new feature to the CF convention, so that the appropriate metric variables could be linked to each data variable using the cell_measures attribute. We do this for cell area and volume, for the same reason of convenience. It would look like something like this on an Arakawa B-grid:

float opottemp(level,yt,xt);
  opottemp:standard_name="sea_water_potential_temperature";
  opottemp:units="degC";
  opottemp:cell_measures="area: areacellot x_length: dxt y_length: dyt";
float uo(level,yu,xu);
  uo:standard_name="sea_water_x_velocity";
  uo:units="m s-1";
  uo:cell_measures="area: areacellou x_length: dxu y_length: dyu";
float dxt(yt,xt);
  dxt:standard_name="cell_x_length";
  dxt:units="m";
  dxt:long_name="distance across tracer cells in the x direction";
float dyt(yt,xt);
  dyt:standard_name="cell_y_length";
  dyt:units="m";
  dyt:long_name="distance across tracer cells in the y direction";
float areacellot(yt,xt);
  areacellot:standard_name="cell_area";
  areacellot:units="m2";
  areacellot:long_name="area of tracer cells";
float dxu(yu,xu);
  dxu:standard_name="cell_x_length";
  dxu:units="m";
  dxu:long_name="distance across velocity cells in the x direction";
float dyu(yu,xu);
  dyu:standard_name="cell_y_length";
  dyu:units="m";
  dyu:long_name="distance across velocity cells in the y direction";
float areacellou(yu,xu);
  areacellou:standard_name="cell_area";
  areacellou:units="m2";
  areacellou:long_name="area of velocity cells";

For a lot of this discussion we were talking about "modified" cell lengths, say dxu_strait and dyu_strait. I understood that these are like dxu and dyu (computed as differences between tracer gridpoints), except that they take narrow channels into account, so that at some gridcells they are smaller than dxu and dyu. Computing the flux through the face of a cell in the x-direction involves the product of x_velocity and dyu_strait, for instance.

The proposed standard names cell_x_length_for_y_velocity and cell_y_length_for_x_velocity would be appropriate for dxu_strait and dyu_strait. They're different quantities from the usual cell_x_length and cell_y_length, because they aren't gridpoint separations, they're values used for computing fluxes. Is that right? The for_[xy]_velocity part of the name is there to indicate their scientific use, not to indicate which grid they're on. Included in the above example, they would look like this:

float dxu_strait(yu,xu);
  dxu_strait:standard_name="cell_x_length_for_y_velocity";
  dxu_strait:units="m";
  dxu_strait:long_name="distance across velocity cells for calculating fluxes in the x direction";
float dyu_strait(yu,xu);
  dyu_strait:standard_name="cell_y_length_for_x_velocity";
  dyu_strait:units="m";
  dyu_strait:long_name="distance across velocity cells for calculating fluxes in the y direction";

Does this make sense?

Happy weekend

Jonathan

[taylor13]

Earlier today (before Jonathan's post), I started to compose a comment about this but got interrupted. My comment started:

Apologies if I've missed something, but if this issue is about defining characteristics of cells and not simply recording the cell widths that are modified for certain purposes, then I think we should consider expanding "cell_measures" to include an option like "effective_cross_section". Just as the cell_measures can record the area of a cell, we could have it record the "width of the cell orthogonal to the direction of the dimension.

So I think that two of us at least support exploring the use of cell_measures* to record this sort of information. Like "cell area" the cell width is useful for those analyzing data.
Karl

*corrected JMG

[atreguier]

Hi @JonathanGregory ,

The solution to have "cell_x_lenth" and "cell_y_length" as standard names seems fine to me. I don't think we need "modified" cell lengths, because once the cells are are modified before running the model, the original values are never used. dyu would be the y-width of "u" cells, used to calculate zonal transport everywhere, whatever the way it has been computed or modified.

The issue of modified lengths is one of the motivations to publish e.g., dyu on esgf, because in that "modified" case if you try to re-compute the dyu approximately from the coordinates of neighbouring points you will not be able to recover something that could approximate the "true" value used by the model at that specific location.

I have never used the "cell_measure" attribute myself, but your suggestion seems great.

[JonathanGregory]

@atreguier, wouldn't you need the unmodified cell lengths (= distances between points on another grid) to calculate derivatives consistently with the model code?

[atreguier]

Hi @JonathanGregory , here is the page in the NEMO manual that explains the narrowing of straits: https://github.com/user-attachments/files/17686527/nemo_manual_handmade_grid_corrections.pdf .
To my knowledge, this is done when the width of one single grid point is significantly larger than the width of the channel in the real world. So, only channels that are one grid point wide are narrowed, and there is land on each side, so the derivative of the along channel velocity in the cross channel direction is never used anywhere. The velocity derivatives that are computed using the modified scale factors are all masked because they fall in land.

[JonathanGregory]

Thanks, @atreguier. I see, yes, the unmodified cell length is not used in the model code. However, that manual page explains that the cell area is still the product of the unmodified cell lengths and hence the cell volume depends on the unmodified length too. For that reason I think we ought to stick to what we'd discussed before: define the plain cell_x_length and cell_y_length standard names for the lengths that relate only to the geometry of the grid, and also define cell_x_length_for_y_velocity and cell_y_length_for_x_velocity for the modified ones used for flux calculations. Is that OK for you and Jenny?

As Karl @taylor13 and I suggested, we can also define new cell_measures to make it easy to find the right variables for the grid of interest. That would be a conventions enhancement, not a standard name issue.