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 davidhassell): Replying to [comment:49 markh]: Dear Mark, > I am struggling more with the proposal of an unordered collection of !DomainAxis instances than i have with an ordered one. I thought one of the objectives was to define the Field's data array, without domain axis ordering this seems not to be delivered. > I think if we are to define the !DomainAxis construct the Field must define an ordered list of them as its domain_axes. I'm sorry to hear that! The ''field domain's'' domain axes are unordered. There can be no order to a ''domain's'' domain axes (what would it mean if there were?). Those that relate to each dimension of the field's ''data array'' do, however, comprise an ordered list which the field knows about. This is the same treatment that auxiliary coordinate and cell measure constructs get (i.e. they know which domain axes relate to the shape of their data arrays), which is nice. > The instance of a Field from my example which you have described does not deliver on some key aspects I require, I will try to explain how: > * the ordering of the dimensions defined by the height_level and time coordinates is not defined; > * my Fields will become extensive in height_level and time, during aggregation; how would my ggregator know which way round to order these dimensions in the data array? This is beyond the scope of the data model. The order of dimensions in your aggregated field's data array is arbitrary and entirely at the whim of your aggregation software. > * you have defined forecast_period and forecast_reference_time as functions of t, suggesting a link to the time coordinate. > * one of these two coordiantes is independent of time, while the other is a function of both time and the previously mentioned coordinate independent of time. I'm afraid I don't understand. In your view of this example, you have only two size 1 domain axes (for height and time) and have only two auxiliary coordinates (''source'' and ''institute''). Where is this 2-d auxiliary coordinate, and what is the "previously mentioned coordinate independent of time"? I don't find your dimension/auxiliary containers useful, particularly when the auxiliary container contains dimension coordinates. > * which is which is either decided by inspection of the data during aggregation or by user preference stated to the aggregator How can a field's coordinates' domain axes not be defined within the field? > * you have defined source and institute as functions of the domain_axis defined by an ensemble_member coordinate: > * this is explicitly not the case, these coordinates are not stated to vary with any other coordinates OK. In this case we need two further, size 1 domain axes for ''source'' and ''institute'': 7 unordered domain axes ({size}): h{1}, t{1}, x{96}, e{1}, y{73} s{1}, i{1} and the ''source'' and ''institute'' auxiliary coordinates span the ''s'' and ''i'' dimensions respectively (as opposed to both spanning ''e'', as I had before). > Does your interpretation of the model allow for a coordinate which has only 1 data value and is not a function of any !DomainAxis? Definitely not. Note that a CF-netCDF scalar coordinate has an implied domain axis, just not one that is encoded in a netCDF file. > Also, when comparing Fields: > * do the domain axis identifiers form part of the comparison criteria? No. > * do the domain axes a coordinate is a function of form part of the comparison criteria? Yes. How else can you ascertain if two constructs are equal or equivalent? The domain axes' ''identifiers'' are not used, but their physical meanings (ascertained from coordinates which span them) are used. As an empirical aside, the proposed fully general aggregation rules (#78) are entirely defined on the the data model as I see it, and they work just fine in the cf-python library (as do field combination with broadcasting and field comparison). I'll shortly be posting more about this on the general list. All the best, David -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/95#comment:50> 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.
