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]

Dear Jenni

I think cell_x_width and cell_y_width would be OK for the widths that you could calculate from gridpoints (from the tracer gridpoints for the cells of the velocity grid, for instance). I fear it might be misleading to use these names for the quantities which are "artificially" narrowed, using @atreguier's word. That's why I suggest the longer term ratio_of_ocean_y_transport_per_unit_thickness_to_sea_water_y_velocity, or the analogous one for x, which I believe describes the physical meaning of the quantity you're interested in. What do you and others think of that?

Best wishes

Jonathan

[jmecki]

Hi Jonathan,

While I believe your suggestion would be technically more accurate, I think it might be confusing and misleading to people trying to find the variable they are looking for (i.e. dx and dy for grid boxes of interest). That name also suggests that it might be time variable, which shouldn't be the case. Therefore, I prefer the simpler names for it i.e. cell_x_width and call_y_width. Is there a possibility to include in the description of the variable name that they should include manually/artificially narrowed grid box widths?

[JonathanGregory]

It's possible someone might want a standard name for the true width of the cell, which would be inconvenient if we had defined cell_x_width to mean an artificially narrowed version which isn't really the cell width. How about cell_x_width_for_ocean_transport?

[taylor13]

I agree that if we go with "cell width", it needs to be modified in some way. "for ocean transport" is good. I had thought of "modified_cell_x_width", which is more general, but perhaps less easily understood.

[ChrisBarker-NOAA]

in NEMO the "scale factors" (the dx,dy, used in the disctretized equations)

The variables I'm looking for are basically the equivalent of the NEMO variables 'e1t, e2t, e1u, e2u, etc...'

what does NEMO call these in its docs? are there "wordier" terms than e1, e2 ?

I really don't like this: ratio_of_ocean_y_transport_per_unit_thickness_to_sea_water_y_velocity -- yes, that's how you can use it, but it's kind of like using ration_of_force_to_acceleration rather than mass :-)

modified_cell_x_width is getting closer -- but not ideal -- virtual_cell_width, analytical _cell_width, computational_cell_width effective_cell_width? -- spitballing here ....

[JonathanGregory]

@ChrisBarker-NOAA. Are you happy with cell_x_width_for_ocean_transport? That describes its purpose, I think.

[jmecki]

Thanks for everyone's input. I think that using cell_x_width_for_ocean_transport might be a bit too specific and just addressing one use for these values. Having dx and dy available (along with thkcello) would make it easier to compute things like section averages. For accurate computations of these things it is best to use the same values as the ones used in the ocean model and for some models the values of dx and dy are part of the grid definition of the model. Furthermore, I don't understand why the dx and dy values can't have a name defined for them, even if they can for the most part be derived from the grid box verticies, however fiddly that might be and dependent on Arakawa grid used. Do we need to have a specific purpose of a variable to have a name defined for it? dx and dy ultimately have several uses not just transport computations.

My preferred suggestion is @ChrisBarker-NOAA suggestion of effective_cell_x_width . This will eliminate the suggesting that these values are only needed for transport computations.

Another thing, the values of dx and dy differ on the t,u,v,,w and f grid points. Do we need anything that specifies the grid point? If so, that would also be needed for cell_thickness, since that differs on the different grid points. How is the naming for this typically handled? Just in the short variable name?

[taylor13]

It would be difficult for those not "in the know" to understand what is meant by "effective cell width". What other quantities reported from a model need this modified width to compute a section average?

[JonathanGregory]

Dear Jenny @jmecki

I agree with Karl, because standard names are intended to identify well-defined geophysical quantities, so that data-users can tell whether variables from different sources are the "same thing". "Effective cell width" is generic. In other models or applications, other quantities might be described like that. That is why I suggested "for transport", as a description of the purpose for which this version of the cell width is used. Karl's question is useful: what other kinds of calculation use this effective cell width? If my suggestion is too specific, we can probably think of something more general that describes the physical purposes for this quantity.

I think the dx and dy values computed from the gridpoints would be called cell_x_width and cell_y_width if you need standard names for those too. As you've explained, the effective width for transport calculations is a "modified" cell width, not the actual cell width, so they shouldn't share the same standard name. They have different geoscientific purposes.

No, we would not indicate in the standard name which of the grids it applies to, because the grid is described by the coordinates. For different grids they could be given different PCDMI names (I don't know the practice with that), but they'd have the same CF standard name, because a physical quantity is the same regardless of the locations of its gridpoints.

Best wishes and thanks for pursuing this

Jonathan

[davidhassell]

Hello,

Just a specific comment: Would the names cell_x_length and cell_y_length be better? I think "length" fits in better with the word "area".

Thanks,
David

[JonathanGregory]

Yes, I agree that length would be better than width. Thanks, David.

[ChrisBarker-NOAA]

standard names are intended to identify well-defined geophysical quantities, so that data-users can tell whether variables from different sources are the "same thing".

This is critical, actually -- it may well be that gird metrics are by definition model specific -- ROMS may use it differently than NEMO, etc. So perhaps a standard name is simply not appropriate for this kind of thing.

"Effective cell width" is generic. In other models or applications, other quantities might be described like that. That is why I suggested "for transport"

The generic name is deliberate, because the width (or length) or the cell is used for multiple calculations -- and outside of standard names anyway, we avoid having two ways to describe the same thing in CF -- i.e. generic is what we are going for :-)

But again, this may be pointing to this not being appropriate for a standard name -- are there any other analogous standard names for things like grid metrics?

@jmecki: I suggest you take a look at:

https://sgrid.github.io/sgrid/

It isn't (and may never be) a part of CF, but it is supposed to be CF compatible, and that may be a better place to define these sorts of metrics.

It's managed here:

https://github.com/sgrid/sgrid

And has not seen any activity for a while, but it is being used, at least a bit :-)

[JonathanGregory]

@ChrisBarker-NOAA. Yes, "we avoid having two ways to describe the same thing in CF". That applies to standard names as well. We take great care to avoid giving a new standard name to a quantity that already has one. But the cell length according to the grid is not the same thing as the "artificially narrowed" cell length for ocean transport calculations (or some other description that better describes what it is used for). That is why they need different standard names. Yes, it is consistent with past practice to give standard names to grid metrics. There are existing standard names of cell_area and cell_thickness.

[taylor13]

I think we need to wait to hear from @jmecki as to how the cell length quantity is used (besides in computing transports) before we can come up with a more general term that is still specific enough to be able to distinguish it meaningfully from simply "cell_length".

[ChrisBarker-NOAA]

The question is whether the cell metric at hand is used in all (many, most?) models the same way -- or at least having the same meaning. If so, then a standard name may make sense, if not, then maybe not.

[atb299]

Hi all,

As a suggestion, how about defining names for cell_x_width and cell_y_width for the widths that you could calculate from gridpoints, plus cell_x_width_scale_factor and cell_y_width_scale_factor? This could be a clearer and more generic way for modelling centres to provide the information that is required. The names could be used for any model (ocean, atmosphere, ice, ...). There may be cases, existing or future, where cell widths are not the distance between adjacent grid points and/or are for use other than computing ocean transport.

[JonathanGregory]

Thanks for your comment, Adam @atb299. If it's easier to provide a scale factor than the modified cell length, we could certainly consider giving it a standard name. However, I still think it's necessary for the standard name to mention what the factor is intended for. The purpose of standard names is to indicate what quantities are "the same thing". Two quantities, both named "cell length scale factor", which come e.g. one from an ocean model, the other from a land ice model, are unlikely to refer to the geoscientific concept, so they shouldn't have the same standard name. If "ocean transport" is too limited to describe all the purposes for the scaled "artificially narrowed" cell length in NEMO, how would you characterise it, generally?

[taylor13]

I also would like to know what more general application is envisioned for this quantity beyond being needed to compute ocean transports. This is why I made the comment above and the follow up.

[atb299]

@JonathanGregory, @taylor13, I've spent a little time today trying to find out whether there are use cases beyond ocean transports, such as reducing volume or area of a cell which could affect calculation of volume integrals or surface fluxes for example. I've not found any yet, but that doesn't mean they don't exist.

I have found that it's not just NEMO that this affects. Edited scale factors are mentioned in NorESM.

[ChrisBarker-NOAA]

I have found that it's not just NEMO that this affects.

thanks -- and I"m sure there are other model's that do similar things as well. The question is whether all (most, many?) models do these kinds of things the same way -- that is, is there a single "thing" that we can define a standard name for -- or is the meaning of these these grid metric adjustments particular to each model?

I've done a lot of work with ROMS results for example -- and I go to the ROMS docs to make sure I understand what the outputs mean. maybe they are the same for all Arakawa C grids -- or all grids? but I doubt it :-(

I guess what I'm getting at is that it may not be possible to have a. standard name for everything -- and that's OK.

[taylor13]

Nice find, @atb299! There is one sentence in the NorESM documentation of real relevance:

The metric scale factors are edited to the realistic width of the Strait of Gibraltar so that strong velocity shears can be formed, enabling realistic mixing of Mediterranean water entering the Atlantic Ocean.

So apparently, one internal model use of the scale factors is to compute more realistic velocities (and shears), so that the mixing parameterization yields a more realistic result. I think this still falls under the category of "for ocean transport" (if velocity can be thought of as a "transport of non-dimensional 'stuff' of unit value").

[larsbarring]

Here is a couple of thoughts from an outside perspective. My understanding is that this scale factor is used to mimic a more realistic channel geometry (in particular its cross-section) than what is allowed by a particular model grid resolution. This is done to allow the model to produce more realistic through-channel flow. As such this factor is not directly adjusting the flow as such.

How about grid_adjustment_factor_for_channel_flow, if there is a x- and y-component of this factor one may add _in_x_direction_ etc. Other phrases that comes to mind are _scale_factor_, _cross_channel_geometry, _channel_cross_section, _channel_width (noting that "width" is a length/distance measure more or less orthogonal to channel_length).

[atb299]

How was this issue resolved when the name "thkcello/cell_thickness" was accepted? Models that use partial bottom cells define cell thicknesses that are different than the reference grid. Users have to rely on the long_name or other attributes to know which point on a grid cell the thickness refers to. Could use cases for cell_x_width be specified in the long_name attribute? This might give some flexibility to how it is used.

[atb299]

@larsbarring

As such this factor is not directly adjusting the flow as such.

I think I disagree with this statement. The cell widths are used by the model to compute transports/fluxes through the face of the model cell. If you try to use a different cell width (e.g. the distance between two f points on an Arakawa C grid) to compute transports using velocities offline you will get the wrong answer. Unless the cell widths used by the model are provided it is (almost) impossible to accurately calculate transports for these cells offline.

[JonathanGregory]

Adam @atb299 wrote

How was this issue resolved when the name "thkcello/cell_thickness" was accepted? Models that use partial bottom cells define cell thicknesses that are different than the reference grid.

That's a good question. I don't remember, but I suspect it wasn't discussed. The cell_thickness is probably used for doing vertical integrals, for which it should be the partial cell thickness. I suppose it would also be the right thickness to use for volumetric flow in horizontal directions through the cell. Perhaps the distinction between the "gridpoint" and "narrowed" cell dimension is not required for thickness? If it is needed, we may have to return to that one sometime!

Users have to rely on the long_name or other attributes to know which point on a grid cell the thickness refers to. Could use cases for cell_x_width be specified in the long_name attribute? This might give some flexibility to how it is used.

Certainly you could, but that not be a CF convention, which doesn't standardise the contents of long_name.

Best wishes

Jonathan