search

E3SM-Project / scream

Fork of E3SM used to develop exascale global atmosphere model written in C++
https://e3sm-project.github.io/scream/
Other
76 stars 54 forks source link

Change (and add) rank method and change "dimension" to "extent" in FieldLayout. #872

Open bartgol opened 3 years ago

bartgol commented 3 years ago

The word 'dimension' is ambiguous. Currently, in FieldLayout is used as the "extent" corresponding to each tag. However, the word 'dimension' is useful to identify a "component" of the layout. E.g., if the stored tags are (Column,Component,VerticalLevel), it is natural to refer to Component as the second "dimension" of the layout. This difficulty is evident when trying to document a field-related class, especially when documenting features that have to do with the layout and its indices/extents.

Kokkos already replaced 'dimension' with 'extent', and doing the same in scream might avoid confusion.

As for the rank() method, I'd like to change it to view_rank(), to stress that it is the rank of the multidimensional array used to store the data, as opposed to the rank of the mathematical field. The latter, could also be exposed via a tensor_rank() method. And finally, we could have space_dimension() to specify the number of geometric dimensions of the space where the field is defined. E.g., say we have a layout with (short) tags (COL, VAR, CMP, VL). This is a 2d field (the VAR dimension and the CMP dimension), defined in 3d (2d from the COL tag, and 1d from the VL tag), and will be stored as a 4d view. So tensor_rank()=2, space_dimension()=3, and view_rank()=4.

ambrad commented 1 year ago

@bartgol still relevant?

bartgol commented 1 year ago

Well, I don't know. I do think that some names are somewhat confusing. dimension vs extent is probably not an issue, but the rank of a field is somewhat confusing. I don't think I am going to work on this anytime soon though.