[CF-metadata] Example of forecast data

From: Jonathan Gregory <j.m.gregory>
Date: Fri, 4 Jul 2003 17:22:40 +0100

Dear Ag

> I agree that we should consider this issue as analogous to that of the sigma
> vertical levels. What we have is two new auxiliary coordinate variables,
> forecast_reference_time and forecast_validity_time. They can be identified
> by their standard names and should not cause a problem for software.
> However, if they have standard_names other than "time" then some current
> software will miss assigning the time dimension unless there is an axis="T"
> attribute.

It should be identifiable by its units. The standard (4.4) doesn't require
the standard_name to be "time", just "an appropriate value". This suggests
that units and axis attribute are easier to use for identification.

If we have 2 time dimensions we may have 5 dimensions in all. That might be
a problem - I don't know. If one of the time dimensions is multi-valued and
the other single-valued, perhaps the multi-valued one should be "on the right"
for the sake of applications which expect time as the 4th dim.

> For ultimate flexibility, the forecast_validity_time should have a units
> attribute entirely independent of the forecast_reference_time units
> attribute and is therefore a fully fledged time axis in its own right.

Yes, I agree. Brian's idea of using the ref time in the udunits string for
the forecast reference time is neat, but I still would prefer to have them
separated for robustness and flexibility, as you say.

> Do we want to encourage people who have one analysis and 3 forecast steps
> (00,06,12 and 18hr time steps) to use the old system of just one linear time
> dimension (which would lose valuable metadata regarding the relationship
> between the time steps) or should they follow the 2 auxiliary coordinate
> variable approach? I would suggest that in the long run they want to do the
> latter but right now they would have more luck doing the former.

With one analysis and three forecast steps, I think they should use 2 time
axes, one multi-valued, one single-valued. The 2 auxiliary coordinate vars
are necessary when you have various *combinations* of analysis and forecast
time. In this case, that would mean replicating the analysis time.

> Another related issue brought up by a colleague the other day is encoding
> ensemble simulations. It's a similar issue to forecasts in that you have
> duplicate variables at the same space/time coordinates. Do you think it is
> effectively the same issue as forecasts or do we need an extraneous
> description for ensemble runs?

We discussed this the other day when you visited. I agree with Bryan; ensembles
are a different "source". We could regard the intraensemble standard deviation
and other measures of the ensemble spread as "error" terms, with modifiers in
the standard name as we have agreed in the other thread to identify them.

Back at work in two weeks.

Best wishes

Jonathan
Received on Fri Jul 04 2003 - 10:22:40 BST