Thinking about the ensemble dimension as capturing error is very different from how I would be likely to use it working with regional climate models.
When I see the term 'ensemble', I think of running a model multiple times and then grouping the outputs from those runs together. If the runs differ only in their seed states, then one could interpret the ensemble as representing a particular kind of error (which it sounds like is the case with forecast ensembles), but it's easy to imagine wanting to group together runs that have the same spatio-temporal coverage and resolution but different boundary conditions or model physics, or even ones that come from different models, in which cases 'error' may not really be well-defined or meaningful. Certainly one could calculate the agreement or disagreement associated with whatever it is the ensemble members differ by, but I think that's secondary to the bundling together of a group of identically-structured data sets that have some kind of familial relationship. So I think 'ensemble' is a special case of "I did the same thing a bunch of times, and these outputs all go together" and that it would be more helpful to support that broader usage than to load the definition toward error. Cheers, --Seth **** Seth McGinnis NARCCAP Data Manager Associate Scientist IMAGe / NCAR **** On Wed, 7 Apr 2010 12:14:06 +0100 "Kettleborough, Jamie" <[email protected]> wrote: >Hello Nan, > >one of the aims of using 'realization' was to make this term less tied >to models, though it looks as though this isn't working. So a review is >a good idea. I'm still not sure about tying this to the term 'ensemble' >though. > >I think there are a set of problems around representing errors that are >closely related, and so treating them in a similar way in CF **may** >make CF meta-data easier to use for both human users (fewer concepts to >remember and possible concept transfer from one context to another) and >applications (through reuse of code in slightly different contexts). > >The underlying class of problem is something like: some things have >errors in them, and these errors have complex distributions (not >represented by an analytic function, possibly with covariances between >variables), how do we represent these complex error distributions in CF? >So this could include model based forecasts, forecasts based on >statistical fits to empirical data, and also observations of quantities >(though I'm less clear about the subtleties of obs - and we didn't think >about these in the original proposal). If the error characteristics are >sufficiently complex that simple summary statistics (like standard >deviations) are not enough then a one way of representing these errors >is through a set of sample points, and their weights - from these you >can generate moments of the error distribution, or cumulative >distribution functions, or probability distribution functions. > >The term 'realization' was introduced to try and capture the dimension >of the 'sample points'. In the context of a model based forecast each >ensemble member provides a 'sample point'. The original proposal we >considered using the term 'sample' rather than 'realization', but >thought this was too overloaded a term e.g. grab sample. We also >proposed the standard name 'realization_weight' to represent the other >part of the error characterisation, but I'm not sure it ever made it >through the process. > >Though I guess things aren't quite as clear cut as I've tried to make >them - especially in the context of observations. In some cases the >sample dimension is actually just one of the other dimensions - like >time or space (or both). I don't have enough experience of observations >to say how widely used other ways of generate error characteristics are >(e.g. through computer simulation of an instrument), and if there are >how you would represent the errors and the terms you'd use to talk about >them. > >Another possible complication is that not all uses of ensembles result >directly in a quantitative error estimate of some quantity - so loading >the 'ensemble' dimension towards this use may not be helpful. > >So I think it comes down to something like: > >1. what is the main use of ensembles? >2. is the main use of ensembles a special case of a broader problem? if >yes... >3. does CF gain by accommodating the broader problem? if yes... >4. what are the most useful terms for talking about the broader >problem. >5. if the initial answers to any of the above are wrong, does CF have >the mechanisms to recover - how well would users and applications cope >with 'aliased' dimensions? > >Sorry, there are no concrete proposals in this mail, but I figured a bit >of context behind why we didn't use a standard name based on the term >'ensemble' might be useful. > >Jamie > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Nan Galbraith >> Sent: 06 April 2010 21:30 >> To: John Caron >> Cc: [email protected] >> Subject: Re: [CF-metadata] ensemble dimension >> >> Hi All - >> >> The term realization is, apparently, *perfectly* clear to you >> modelers, but it conveys no information at all to me. >> >> Since it looks like it's going to be adopted, I hope you'll >> provide a really clear definition in the standard - something >> that even an oceanographer will understand. >> >> Thanks! >> >> - Nan >> >> >> John Caron wrote: >> > Jonathan Gregory wrote: >> >> Dear all >> >> >> >> "realization" is fine as a standard name. I had forgotten we had >> >> introduced it. >> >> I withdraw my suggestion of ensemble_member_identifier. >> >> >> >> Thus, the standard name (of realization) can be used to >> identify an >> >> ensemble axis. I think that providing an axis attribute as >> well could >> >> be >> >> helpful: with >> >> spatiotemporal axes we have both methods of >> identification, and it is >> >> possible there might be ensemble axes in which realization >> was a not >> >> a good choice of standard name. >> >> -- >> ******************************************************* >> * Nan Galbraith (508) 289-2444 * >> * Upper Ocean Processes Group Mail Stop 29 * >> * Woods Hole Oceanographic Institution * >> * Woods Hole, MA 02543 * >> ******************************************************* >> >> >> >> _______________________________________________ >> CF-metadata mailing list >> [email protected] >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >_______________________________________________ >CF-metadata mailing list >[email protected] >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
