I agree with Jonathan's summary. I made my points about Thredds and
netcdf in an email on the 1st of November, I don't think they help us
here and now, and we have to get on and do things.
Bryan
On Sun, 2007-03-04 at 16:35 +0000, Jonathan Gregory wrote:
> Dear all
>
> Many people have made thoughtful contributions to this discussion. My
> impression is that through the earlier discussions we reached a consensus on
> a convention for handling ensembles. There was one exception to this, namely
> the issue of whether to use the standard_name attribute for new purposes, or
> define an alternative attribute, but that issue doesn't affect the structure
> proposed. This convention introduces an extra dimension and allow a combination
> of auxiliary coordinate variables to identify the ensemble members along that
> dimension. The convention is adequate for some needs that already exist. That
> is why Paco raised the requirement in the first place. Balaji gives two use-
> cases for it. The combination of auxiliary coordinates is really doing the job
> of the "lower-level" identification (members within the ensemble) that Balaji
> describes, but early on in the previous discussion it appeared useful to have
> this factorised into various attributes rather than in a single string.
>
> I agree that because this axis doesn't have a meaningful monotonic coordinate
> variable, you can't extract a range from it. That's because it's discrete, not
> continuous. This is not an unprecedented situation. If you have a data variable
> containing timeseries or vertical profiles at scattered points, or trajectories
> from a number of parcels, you will have a similar kind of index dimension, with
> auxiliary coordinates providing locations and other identification. You can
> usefully subset such an axis, as people have commented. Subsetting may be a bit
> more awkward for analysis softare, but it is an essential operation. You might
> do it with continuous axes as well (e.g. to extract the Januaries from a time
> axis of months).
>
> It is also a limitation that the data have to be on the same space-time grid.
> For many analysis operations, however, this is necessary, even if the data were
> not generated like that. In Balaji's case of the AR4 archive, the models do not
> have the same grid. It is necessary to put them on a common grid nonetheless in
> order to produce some familiar diagnostics such as appear in the AR4 and recent
> papers, like the average lat-lon field of surface temperature change, or the
> time-depth field of ocean temperature change averaged over models with
> volcanoes. Even if the archive did not originally hold that data like that, I
> am sure that somewhere along the way the ensemble dimension will be needed.
>
> In regard to John's point, it's true that models don't generate all the same
> quantities. But one purpose of standard names is to indicate which quantities
> can be regarded as equivalent among models. You would put surface temperature
> from various models in a single data variable with an ensemble dimension if
> the data variables from the various models already had the same standard_name.
>
> It is certainly true that it would be good to have a solution that *could*
> deal with data on different grids. We can't do that with the proposal we have
> now. It may well be that netCDF-4 will offer a good technical solution for
> that. However, I don't think we ought to wait for it. We have a good solution
> now for cases which are of immediate practical relevance. If we find later that
> a more general solution is efficient for these cases too, we can support both.
> That would be fine. CF is always going to evolve for new needs and technology.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Tue Mar 06 2007 - 01:37:45 GMT
