Dear Jonathan,
Thanks for the answer.
A NetCDF file with multi-forecast system ensemble data requires, at
least, the experiment id to be a dimension of the file. For instance,
ensembles generated with different models, which are part of the same
multi-model ensemble forecast, need to be identified in case the user
wishes to give different weights to the models or needs to bias correct
them separately. That is the reason why the information can not be
encoded as global attributes and we require the new standard names.
I agree with you that using strings for forecast_system_version_number
and forecast_method_number would be ideal, so we'll try this option.
Concerning the use of time coordinates, we can try to use two variables
(reftime and leadtime) with standard names forecast_reference_time and
forecast_period but using a single time dimension, as in your example of
structure (b). I prefer the use of forecast_period because it makes more
obvious that we are dealing with forecasts.
Best regards,
Paco
Jonathan Gregory wrote:
> Dear Francisco
>
> The metadata you propose for describing experiments is the kind of information
> that can be stored in the attributes institution, source etc. (in CF 2.6.2),
> especially if you standardised them for your purposes. There have been
> previous postings about standardising discovery metadata of this kind. If
> you can use these attributes, you do not need standard names for them.
>
> However, is it your intention to have data variables with experiment, centre
> etc. as dimensions? In that case you may need standard names for them, I agree.
> Such variables would have a lot of dimensions.
>
> I would advise against codes for forecast_system_version_number and
> forecast_method_number. Even with online lookup tables, we avoid codes in
> the CF convention because they are not self-describing. Could you not make
> these strings as well?
>
>> - We use the variables "forecast_period" and "forecast_reference_time"
>> as independent time variables employed to define the two time axes of a
>> forecast dataset with several start dates, ie, both "forecast_period"
>> and "forecast_reference_time" are multivalued. We believe that
>> "forecast_period" cannot have time units referenced to a specific date
>> as "forecast_reference_time" does. This is to prevent having in the file
>> forecasts with the same verifying date but produced from a different
>> start date (and, hence, intrinsically different). An alternative would
>> consist in introducing an index dimension and make two one-dimensional
>> auxiliary time coordinate variables with this dimension, as suggested by
>> Jonathan Gregory in the thread "file with both run time and forecast
>> (valid) time coordinates".
>
> In the earlier discussion which led to my posting
> http://www.cgd.ucar.edu/pipermail/cf-metadata/2006/001008.html
> we decided we did not need to have two-dimensional time. It is true that
> you could have separate axes for forecast_reference_time and forecast_period
> (case iv in that posting), if all combinations exist, but is it necessary?
> The argument is that it is simpler for the CF standard to use 1D auxiliary
> coord variables, because then one structure can handle many different cases.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
________________________________________
Francisco J. Doblas-Reyes
European Centre for Medium-Range
Weather Forecasting (ECMWF)
Shinfield Park, RG2 9AX
Reading, UK
Tel: +44 (0)118 9499 655
Fax: +44 (0)118 9869 450
f.doblas-reyes at ecmwf.int
_______________________________________
Received on Tue Oct 17 2006 - 10:45:48 BST
