Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boundary variables for auxiliary coordinates of more than two dimensions #527

Open
JonathanGregory opened this issue Jul 2, 2024 · 1 comment · May be fixed by #547
Open

Boundary variables for auxiliary coordinates of more than two dimensions #527

JonathanGregory opened this issue Jul 2, 2024 · 1 comment · May be fixed by #547
Labels
enhancement Proposals to add new capabilities, improve existing ones in the conventions, improve style or format

Comments

@JonathanGregory
Copy link
Contributor

Section 7.1 on "Cell boundaries" contains the following text, about providing boundary variables for auxiliary coordinate variables of more than two dimensions:

Bounds for multi-dimensional coordinate variables with p-sided cells

In all other cases, the bounds should be dimensioned (...,n,p), where (...​,n) are the dimensions of the auxiliary coordinate variables, and p the number of vertices of the cells. The vertices must be traversed anticlockwise in the lon-lat plane as viewed from above. The starting vertex is not specified.

There is no example given. I suppose it must mean something like this for three dimensions:

variables:
  float x(nk,nj,ni);
    x:bounds="x_bounds";
  float x_bounds(nk,nj,ni,p);

Since it talks about traversing the vertices clockwise in the lat-lon plane, it must be concerned with horizontal faces of the 3D cells. A horizontal coordinate variable only has to be 3D (rather than 2D) if the cells aren't aligned in vertical columns. Do you agree with this interpretation? If so, we should clarify it. 3D cells don't just have horizontal faces, so this convention is of restricted use. For a more general treatment of bounds in two dimensions, we could refer to UGRID.

Cheers, Jonathan

@JonathanGregory JonathanGregory added the defect Conventions text meaning not as intended, misleading, unclear, has typos, format or language errors label Jul 2, 2024
@JonathanGregory JonathanGregory added enhancement Proposals to add new capabilities, improve existing ones in the conventions, improve style or format and removed defect Conventions text meaning not as intended, misleading, unclear, has typos, format or language errors labels Sep 20, 2024
@JonathanGregory
Copy link
Contributor Author

Dear all

I propose the following changes to remedy the defect described above in Sect 7.1 "Cell boundaries". In addition I propose to insert some new subsection headings, explanatory text, and rearrangement of text in Sect 7.1, to improve clarity. I don't believe this is any change to the meaning of the convention, except for one small generalisation (at the end). On account of that, and because the text changes are quite extensive, I've relabelled the issue as an enhancement.

The proposed changes are listed below. You might find it easier to look at the pull request or the HTML of the modified document.

Cheers

Jonathan

  • On re-reading, I suppose that "multidimensional" is referring to the dimensionality of the arrays, rather than the physical space. To clarify this, I've propose deleting this word, and adding a sentence to the end of the first paragraph of Sect 7.1: "CF can currently describe boundaries for cells which have one or two spatial dimensions, but does not provide conventions to describe the boundaries of cells with three spatial dimensions. Please refer to UGRID for development of such conventions."

  • Between the second and third paragraphs of Sect 7.1, insert heading "7.1.1 Boundaries and formula terms".

  • Delete the short paragraph, "Applications that process cell boundary data often times need to determine whether or not adjacent cells share an edge. In order to facilitate this type of processing the following restrictions are placed on the data in boundary variables." This paragraph is unnecessary because the following subsections have specific statements about contiguousness.

  • Promote the bold text "Bounds for 1-D coordinate variables" to become the heading for new subsection 7.1.2, remove the indentation of the following lines, and correct the typo in "identically".

  • Move Example 7.2 into 7.1.2. It is concerned with a 1D latitude axis, but currently it appears at the end of 7.1, after the multidimensional case.

  • Modify the bold text "Bounds for 2-D coordinate variables with 4-sided cells" to "Bounds for horizontal coordinate variables with 4-sided cells", promote it to become the heading for new subsection 7.1.3, and remove the indentation of the following lines.

  • I propose that we modify the first sentence in 7.1.3 to provide a bit more context and explanation, from

In the case where the horizontal grid is described by two-dimensional auxiliary coordinate variables in latitude lat(n,m) and longitude lon(n,m), and the associated cells are four-sided, then the boundary variables are given in the form latbnd(n,m,4) and lonbnd(n,m,4) ...

to

There is a common case of a rectangular horizontal grid, with four-sided cells, whose two axes are not latitude and longitude (e.g. it uses a map projection from <> or a curvilinear grid, such as the tripolar ocean grid). In that case, two-dimensional auxiliary coordinate variables in latitude lat(n,m) and longitude lon(n,m) may be provided as well. Since the sides of the cells do not generally have constant latitude or longitude, all four vertices must be specified individually. Therefore the boundary variables for the two-dimensional auxiliary coordinate variables are given in the form latbnd(n,m,4) and lonbnd(n,m,4) ...

  • The next paragraph describes the anticlockwise traversal of the four-sided cell, but does not require this ordering. I'm certain we have always required it, as is indeed stated in the final paragraph about the "multidimensional cells". Therefore I have rephrased the present paragraph to state this requirement as well.

  • Move Example 7.3 into 7.1.3. It illustrates the 2-D 4-sided case, but currently it appears at the end of 7.1, after the multidimensional case. Change its title from "Cells in a non-rectangular grid" to "2-D cells in a non-latitude-longitude grid", because the grid is logically rectangular (64,128).

  • Modify the bold text "Bounds for multi-dimensional coordinate variables with p-sided cells" to "Bounds for coordinate variables with p-sided cells in two spatial dimensions", and promote it to subsection heading 7.1.4, with the following text:

In the general case of a grid composed of polygonal cells in two spatial dimensions with p sides and vertices, or a mixture of polygons where p is the maximum number of sides and vertices, the grid could have one, two or more dimensions, depending on how it is organised logically (e.g. as a 1-D list or a 2-D rectangular arrangement). The boundary variables for the auxiliary coordinate variables are dimensioned (...,m,p), giving coordinates for the p vertices of each cell, where m are the horizontal dimensions. If the cells are in a horizontal plane, their vertices must be traversed anticlockwise in the longitude-latitude plane as viewed from above. The starting vertex is not specified.

The case of a 2-D horizontal coordinate variables with 4-sided cells (Section 7.1.3) is a particular case, with p=4 for boundary variables dimensioned (n,m,p), where n and m are horizontal dimensions. See also <> for conventions describing horizontal cells with more complicated geometry and topology.

This is a small generalisation to admit the possibility of 2D cells in other than the horizontal plane e.g. in (height,latitude). I'm sure CF is being applied to those cases, and they might need 2D auxiliary coordinates. I haven't made the requirement for the vertices to be traversed in a right-handed way apply to cases apart from the horizontal plane, where we already have that requirement.

@JonathanGregory JonathanGregory linked a pull request Sep 20, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Proposals to add new capabilities, improve existing ones in the conventions, improve style or format
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant