Hi Ag and Jonathan,
Using suggestion (i) from Jonathan's list Ag's example of the 24-hr
forecast would look like this:
variables:
double atime(atime)
atime:standard_name = "forecast_reference_time" ;
atime:units = "hours since 1999-01-01 00:00" ;
double time(time);
time:standard_name = "time" ;
time:units = "hours since 1999-01-01 00:00" ;
float temp(time,atime,level,lat,lon);
temp:long_name = "Air temperature on model levels" ;
temp:standard_name = "air_temperature" ;
temp:units = "K" ;
data:
time = 24 ;
a_time = 0 ;
Note that I have made use of the standard name "forecast_reference_time" to
identify the analysis time.
While this approach is very general, and easily extended to Jonathan's case
(ii) with multiple validity and analysis times, it seems overly complicated
for the simple case of a series of forecasts from a single analysis. I'd
like to propose another option, namely
variables:
double time(time);
time:standard_name = "forecast_period" ;
time:units = "hours since 1999-01-01 00:00" ;
float temp(time,level,lat,lon);
temp:long_name = "Air temperature on model levels" ;
temp:standard_name = "air_temperature" ;
temp:units = "K" ;
data:
time = 24 ;
In this example I've used the standard name "forecast_period" rather than
"time" to identify the validity time. The proposal is that when the
standard name "forecast_period" is used to identify a time coordinate, that
the reference date part of the time units is to be interpreted as the analysis
time.
Using this convention Ag's example with 3 variables at the same validity
time but different analysis times
> 20030101 12:00 analysis
> 20030101 00:00 analysis 12hr forecast
> 20030101 06:00 analysis 6hr forecast
would be expressed as follows:
variables:
double time1(time1);
time1:standard_name = "forecast_period" ;
time1:units = "hours since 2003-01-01 00:00" ;
double time2(time2);
time2:standard_name = "forecast_period" ;
time2:units = "hours since 2003-01-01 06:00" ;
double time3(time3);
time3:standard_name = "forecast_period" ;
time3:units = "hours since 2003-01-01 12:00" ;
float temp1(time1,level,lat,lon);
temp1:long_name = "Air temperature on model levels" ;
temp1:standard_name = "air_temperature" ;
temp1:units = "K" ;
float temp2(time2,level,lat,lon);
temp2:long_name = "Air temperature on model levels" ;
temp2:standard_name = "air_temperature" ;
temp2:units = "K" ;
float temp3(time3,level,lat,lon);
temp3:long_name = "Air temperature on model levels" ;
temp3:standard_name = "air_temperature" ;
temp3:units = "K" ;
data:
time1 = 12. ;
time2 = 6. ;
time3 = 0. ;
Brian
On Tue, Jun 10, 2003 at 03:35:44PM +0100, Stephens, A (Ag) wrote:
> Dear Jonathan,
>
> I agree that using the size-one axes is a sensible way to denote the
> metadata and the four examples seem sensible.
>
> I think the panacea is a metadata description (and software analysing it)
> that could allow combinations of forecasts and analyses to be compared that
> all represent the exact same time-step (in realtime). Such as:
>
> 20030101 12:00 analysis
> 20030101 00:00 analysis 12hr forecast
> 20030101 06:00 analysis 6hr forecast
>
> I think the key will be how software can deal with it. Most of the packages
> I am familiar with do not understand the concept of forecasts and they just
> reduce a forecast step to a time-stamp and forget the relationship to an
> analysis. I have e-mailed the cdat-discussion list to enquire whether cdat
> has a way of dealing with forecasts.
>
> Kind regards,
>
> Ag
> -------------------------------------------------------------
> Ag Stephens Ph : +44 (0)1235 446220
> Data Scientist, Fax: +44 (0)1235 446314
> British Atmospheric Data Centre,
> Rutherford Appleton Laboratory,
> Chilton, Didcot, OX11 0QX, U.K.
> Email: A.Stephens at rl.ac.uk Web: http://badc.nerc.ac.uk
> -------------------------------------------------------------
>
>
> > -----Original Message-----
> > From: Jonathan Gregory [mailto:j.m.gregory at reading.ac.uk]
> > Sent: 10 June 2003 09:24
> > To: Stephens, A (Ag) ; cf-metadata at cgd.ucar.edu
> > Subject: Re: [CF-metadata] Example of forecast data
> >
> >
> > Dear Ag
> >
> > We have had discussions about how to represent forecast time,
> > but so far not
> > put anything in the standard because we didn't have potential
> > users. Evidently
> > we have now!
> >
> > The methods earlier discussed all used the idea that forecast
> > time would have
> > a separate time dimension from analysis time. This seems to
> > be a more flexible
> > approach than giving a special interpretation to bounds. What
> > do you think of
> > the below? Your case would appear to be a simple kind of (i),
> > with a size-one
> > forecast time axis and a size-one analysis time axis. Using
> > size-one axes is
> > a convenient way of attaching metadata with units etc., as we
> > do for example
> > by having a size-one vertical axis to indicate a quantity at
> > 1.5 m height.
> >
> > Best wishes
> >
> > Jonathan
> >
> >
> > Four cases were identified:
> >
> > (i) A forecast run with multiple forecast periods (12 h, 24
> > h, 36 h, etc.)
> > from a single analysis. This can be done with a size-one
> > analysis time axis
> > and a separate validity time axis. If the reference time for
> > the validity time
> > units is the analysis time, the values of the validity time
> > coordinates equal
> > the forecast period.
> >
> > (ii) Multiple validity and analysis times, where all
> > combinations exist. This
> > can be done with 2 axes.
> >
> > (iii) Forecast runs with multiple forecast periods from
> > various analyses,
> > where all combinations exist. This is also a 2D case, where
> > the analysis time
> > is a time axis with a reference time, and the forecast period
> > is plain elapsed
> > time. You have to add the forecast period to the analysis
> > time to get the
> > validity time. The forecast period is a time offset.
> >
> > (iv) Multiple validity and analysis times, where not all
> > cases exist, for
> > instance forecasts out to a given validity time from
> > successive analyses. This
> > can be done by using a single index dimension, with validity
> > and analysis time
> > coordinates having this dimension pointed to by the
> > coordinates attribute.
> >
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Tue Jun 10 2003 - 17:03:53 BST
