Hi Jonathan and Ag,
I appreciate Jonathan's point that giving the reference time part of the
time units a special meaning (i.e., analysis time) can be broken if
a "forecast_period" time coordinate is modified by changing that
reference time. There are, of course, many ways to break metadata if the
conventions are not followed. Using tools that are not convention aware
involves the risk of producing broken metadata. But another major cause of
broken metadata is not getting it right in the first place. I'm advocating
what I perceive to be a simpler representation that data writers are more
likely to understand and get right the first time.
I'm not arguing against the use of any of the 4 cases Jonathan outlined in
his initial response. They are all perfectly legal with no new additions
to the current convention. The necessary standard name to identify an
analysis time already exists (forecast_reference_time). My suggestion for
a special treatment of a time coordinate identified by the standard name
forecast_period (which also already exists) is the only proposal that would
require an addition to the convention.
> I am pondering how this solution would scale to more complicated examples
> such as:
>
> 20030101 12:00 analysis (at 00hr) and 12hr,36hr forecasts
> 20030101 00:00 analysis 6hr,12hr,18hr,24hr forecasts
> 20030101 06:00 analysis 6hr,18hr forecasts
My solution is:
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 = 6., 12., 18., 24. ;
time2 = 6., 18. ;
time3 = 0., 12., 36. ;
Brian
On Thu, Jun 12, 2003 at 12:22:54PM +0100, Stephens, A (Ag) wrote:
> Dear Brian and Jonathan,
>
> At first glance I like all the solutions but my major concern is how
> software will get to grips with this new dual-time concept. I asked Bob
> Drach if CDAT had any way of representing forecasts and it does not yet, but
> their group has a project that requires analysis of forecast data so they
> are thinking about it. It would be good to keep the communication going
> between to the two groups on this.
>
> What I like about Jonathan's most recent solution (and Brian's first
> solution) is that the temperature variable is only defined once in relation
> to any number of dimensions.
>
> I am pondering how this solution would scale to more complicated examples
> such as:
>
> 20030101 12:00 analysis (at 00hr) and 12hr,36hr forecasts
> 20030101 00:00 analysis 6hr,12hr,18hr,24hr forecasts
> 20030101 06:00 analysis 6hr,18hr forecasts
>
> In this case I think we would have to define all the timesteps and include
> lots of missing values in the data (which doesn't sound ideal).
>
> I am grappling with it but keep coming up with problems in each
> representation. Has this problem been dealt with by other parts of the
> community previously? Have the Met Office produced inhouse software that can
> understand the analysis/forecast duality?
>
> Sorry for the lack of suggestions. It's a tough one.
>
> Ag
>
> > -----Original Message-----
> > From: Jonathan Gregory [mailto:j.m.gregory at reading.ac.uk]
> > Sent: 11 June 2003 17:01
> > To: cf-metadata at cgd.ucar.edu
> > Subject: Re: [CF-metadata] Example of forecast data
> >
> >
> > Dear Brian and Ag
> >
> > It might be nicer in Ag's example to have a single variable.
> > This could be
> > done with a size-one validity time dimension and a size-three
> > forecast time
> > dimension. You could still have a forecast period:
> >
> > dimensions:
> > timea=3;
> > timef=1;
> > variables:
> > double timea(time1);
> > timea:standard_name = "analysis_time";
> > timea:units = "hours since 2003-01-01 00:00" ;
> > double fperiod(timea);
> > fperiod:standard_name="forecast_period";
> > fperiod:units="hours";
> > double timef(time2);
> > time3:standard_name = "forecast_validity_time" ;
> > time3:units = "hours since 2003-01-01 12:00" ;
> > float temp1(timef,timea,level,lat,lon);
> > temp1:long_name = "Air temperature on model levels" ;
> > temp1:standard_name = "air_temperature" ;
> > temp1:units = "K" ;
> > data:
> > timea = 0., 6., 12.;
> > fperiod=12., 6., 0.;
> > timef = 0. ;
> >
> > However, the forecast period may not really be necessary as
> > it should be
> > pretty easy to subtract the analysis time from the validity time.
> >
> > Brian's other example is the reverse case of multiple
> > forecasts from one
> > analysis time. The idea of using the reference time in the
> > time units to
> > indicate the analysis time, and thus eliminate a size-one
> > dimension, is neat
> > but I wonder if it is really robust? It means that one could
> > not reprocess
> > the time units without care. Usually the reference time could
> > be changed in
> > time units (altering the time values consistently) without
> > any consequence.
> >
> > Best wishes
> >
> > Jonathan
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu
> > http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
> >
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu Jun 12 2003 - 09:31:02 BST
