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
>
Received on Thu Jun 12 2003 - 05:22:54 BST
