This message came from the CF Trac system. Do not reply. Instead, enter your comments in the CF Trac system at https://cf-pcmdi.llnl.gov/trac/.
#95: Development of CF 1.5 Data Model -----------------------------+---------------------------------------------- Reporter: markh | Owner: [email protected] Type: task | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by jonathan): Dear Mark This appears to be a repetition of a debate we have already had, and I thought we had settled. Back in my summary in [https://cf- pcmdi.llnl.gov/trac/ticket/95#comment:6 comment 6] I wrote Whether dimensions have an independent identity in the field. Could we call a 1D axis a domain axis? Our CF data model would then distinguish domain axis construct (corresponding to netCDF dimension and the 1D coordinate variable of the same name, if there is one) and auxiliary coordinate construct (corresponding to a CF-netCDF auxiliary coordinate variable). Bryan supported the concept of domain axis construct. Mark expressed concerns about this point. Following subsequent useful discussions with Mark, we have changed our document. We now have a domain axis construct, whose only function is to indicate the existence of a dimension of the domain, and provide the size of the dimension. That means the dimension coordinate construct (corresponding to the Unidata 1D netCDF coordinate variable) and the auxiliary coordinate construct (corresponding to the CF- netCDF 1D or multi-dimensional auxiliary coordinate variable) are more similar than we had before. This feels like an improvement. Both types of coordinate construct refer to the domain axes. The field data array also refers to the domain axes for its dimensions, but it does not have to include dimensions of size one. This is because CF-netCDF allows data variables to omit dimensions of size one, by using scalar coordinate variables. In previous discussons, I don't think anyone else has been concerned about this treatment. I wonder what you think now about our current version, Mark? In [https://cf-pcmdi.llnl.gov/trac/ticket/95#comment:10 comment 10], you wrote As yet I do not see the benefit delivered by having the domain axis as a separate construct, referenced by the Field. However, I think the risk of this causing serious problem can be mitigated by the constraints I have detailed, binding domain_axis collections to the Field data properties and mediating the shape constraints between Fields and other constructs. I took that as acquiescence, although without enthusiasm, by you. :-) But I have to confess that I do not understand the meaning of "binding domain_axis collections to the Field data properties and mediating the shape constraints between Fields and other constructs." Perhaps that's what I've got to understand now! Anyway, in the most recent postings I agree with David. I think that the domain axis construct in the CF data model corresponds to the dimension in a CF-netCDF file. It indicates that a certain dimension exists and has a particular size. Just as the dimension has an identity in the CF-netCDF file, so the domain axis construct has an identity in the abstract representation of the data model. As you say, the particular way an identity is implemented depends on the language or file format (a dimension is identified by a name in CDL, but more fundamentally by an integer in a netCDF file, for instance), but that is not essential to the data model. Because the axis constructs each have a unique identity, the field construct knows which of the axes the data array is dimensioned with. They are not identified by their order or size, but by who they are. In the same way, Mark Hedley, David Hassell and Jonathan Gregory each have unique identities. Two of them are employed by the Met Office, two of them are employed by the University of Reading, and two of them are professional software designers, but despite these ambiguities they are distinguishable entities. In the same way, a netCDF data variable might have two dimensions which are the same size, but they are distinguishable because they have different identities. `float data(x)` is not the same as `float data(y)` even if `x` and `y` both have size 10. The axis constructs which are used to dimension a field data array or an auxiliary coordinate array are in a particular order because this order determines the order of the elements of the array. It is safe to omit axis constructs of size one because they make no difference to the order of the elements of the array. Omitting them doesn't mean the field or the coordinate construct is not aware of them. You made another point earlier, that "the Field is too much of an unaware container of clever constructs; I think this perspective should be reversed, with the Field being a smart container of simple constructs." That was nicely put! I don't feel strongly about this, myself. I think you have to read the whole document (both the field and its components) to comprehend the data model, so in a sense it doesn't make any difference where the logical function of each component is stated. The formal description is unaffected by this. However it might be more intelligible to describe the logical functions where the components are first introduced i.e. in the field description, as you say. Best wishes Jonathan -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/95#comment:40> CF Metadata <http://cf-pcmdi.llnl.gov/> CF Metadata This message came from the CF Trac system. To unsubscribe, without unsubscribing to the regular cf-metadata list, send a message to "[email protected]" with "unsubscribe cf-metadata" in the body of your message.
