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" <jamie.kettleborough at metoffice.gov.uk> 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: cf-metadata-bounces at cgd.ucar.edu
>> [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Nan Galbraith
>> Sent: 06 April 2010 21:30
>> To: John Caron
>> Cc: cf-metadata at cgd.ucar.edu
>> 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
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>_______________________________________________
>CF-metadata mailing list
>CF-metadata at cgd.ucar.edu
>http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Fri Apr 09 2010 - 18:40:49 BST
