Dear Jonathan, Chris and other,
_at_Chris, thanks for your contribution to the discussion. very interesting
I don't agree with your comment regarding 3D data variable with 4 coordinates being wrong. I have 3 physical axes and 4 coordinates, yes, but leadtime is a coordinates associated to the same time axis than the forecast_reference_time coordinate.
In other words, I have 2 coordinates sharing the same physical axis. I don't have multiple Time, I have multiple descriptions/partitioning of Time.
I am doing this because I want to associate 2 informations for each time: the reference time and the elapsed time since that reference time (instead of only providing the valid time which is simply the composite of the two with a loss of information). As Jonathan pointed it out, this is discussed in detail in trac ticket 117 and on this mailing list. I have also looked at the discussions from the early 90's on the unidata netCDF mailing list. It took a while to go through, it seems to be a recurrent problem and nobody really solved it so far.
_at_Jonathan,
I started this thread precisely to revive the discussion from trac ticket 117 (btw, I can log in on the trac site but sadly not add any comments to existing tickets(!))
We have a fundamental disagreement: I don't see this as a "multiple time axes" problem, I see it as a "single time axis with multiple time coordinates defined on it" problem. Our preferred solution (so far) is in fact to use all three standard names (time, forecast_reference_time and forecast_period) in the same file but only "time" has the attribute "axis = T". One can see the two other coordinates as "auxiliary coordinates" of the same physical axis. It means having redundant informations (only 2 are needed, the 3rd one can be derived from these 2) but it makes the data files compatible with more tools.
I see two options to move forward:
1) expand the available list of standard names to be able to describe accurately any type of forecasts, analysis, hindcast, etc.
2) recognise that time and processes are decoupled information, deprecates "forecast_reference_time" and "forecast_period" for something more generic like "reference_time" and "time_interval", and finally design a mechanism to describe forecast, hindcast, analysis, etc.
cheers,
/S?bastien
----- Original Message -----
From: "Jonathan Gregory" <j.m.gregory at reading.ac.uk>
To: cf-metadata at cgd.ucar.edu
Sent: Wednesday, 25 October, 2017 13:50:53
Subject: Re: [CF-metadata] various "time" in CF
Dear Sebastien and Chris
The various ways to handle forecast times, analysis times and forecast
periods with multiple time axes have been discussed several times before. Since
there are plenty of use-cases, and it's complicated, it would be good if we
could agree on recommended ways to do it, which could be added to the CF
standard document as examples. The last time this was attempted was over two
years ago, in cf-trac.llnl.gov/trac/ticket/117. Perhaps you could have a look
at that and comment if appropriate, and maybe also my earlier summary, over a
decade ago (!), in mailman.cgd.ucar.edu/pipermail/cf-metadata/2006/001008.html.
Best wishes
Jonathan
----- Forwarded message from Chris Barker <chris.barker at noaa.gov> -----
> Date: Tue, 24 Oct 2017 14:12:33 -0700
> From: Chris Barker <chris.barker at noaa.gov>
> To: Sebastien Villaume <sebastien.villaume at ecmwf.int>
> CC: "cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>
> Subject: Re: [CF-metadata] various "time" in CF
>
> My thoughts:
>
> Example 1:
> >
> > ...
> variables:
>
> >
> > double time(t) ;
> > time:units = "hours since 2010-01-01 00:00:00" ;
> > time:standard_name = "time" ;
> > time:calendar = "gregorian" ;
> > time:axis = "T" ;
> >
> > .... lat/long here ....
> >
> > float data(t, j, i) ;
> > ...
> > data:standard_name = "temperature" ;
> > data:coordinates = "time lat lon" ;
> > ...
> > What is this? Is this an analysis? an observation? or something else?
> >
>
> That should be specified one way or another in the attributes of the data
> variable -- what type of data it is has nothing to do with what time it is
> associated with.
>
> the coordinates attribute specifies that the time axis is described by the
> "time" variable, and the time attributes specify that it is representing
> time, and what units an calendar -- a particular datetime is exactly the
> same regardless of whether it's an analysis or observation, etc.
>
> Indeed, one very might have an analysis and measured data corresponding to
> the same time - in which case having them share a time variable would make
> perfect sense.
>
> Example 2:
> >
> > ...
>
> > variables:
> > double forecast_reference_time(t) ;
> > forecast_reference_time:units = "hours since 2010-01-01 00:00:00" ;
> > forecast_reference_time:standard_name = "forecast_reference_time"
> > ;
> >
>
> again, this is a datetime variable, nothing wrong with using the "time"
> standard name. There is nothing about the fact that it is being used for a
> forecast reference that changes that.
>
>
> > double leadtime(t) ;
> > leadtime:units="hours" ;
> > leadtime:standard_name="forecast_period" ;
> >
>
> This is NOT a datetime -- it is a time-delta (number of hours -- you can't
> map it to a particular date and time) -- not sure what the standard name is
> for that, but it should be different than "time", though the units may make
> that clear enough.
>
>
> float data(t, j, i) ;
> > ...
> > data:standard_name = "temperature" ;
> > data:coordinates = "leadtime forecast_reference_time lat lon" ;
> > ...
> >
>
> here you have a 3D variable with four coordinates -- I think we have a
> problem there.
>
> I _think_ what you want is to have the time coordinates of this variable to
> be forecast_reference.
>
> The leadtime variable would then be a data variable (not a coordinate
> variable) with forecast_reference_time as its coordinate variable.
>
>
> What is this? is it the forecast done back on the 1st January 2010? or is
> > it a hindcast done years later to test the model of today? or is it a
> > forecast from a reanalysis dataset, for instance ERA5? or something else?
> >
>
> There is only so much one can do with standard names, but if you were to
> specify that more, it would be with the attributes of the data variables..
>
> I would tend to think that you'd want to have:
>
> - A time coordinate -- a "Proper" datetime, which is for when the data are
> valid.
> - A data variable for when the forecast (or hindcast) was produced
> - An attribute on the dat variable(s) indicating that it's a hindcast (if
> it is) -- probably the long name.
>
> Proper attributes, probably some on the Dataset, that specify all the rest
> of it.
>
> >
> > extra question for example 2: lets assume it is a hindcast. how will I be
> > able to distinguish this hindcast done today from the hindcast I am going
> > to do in 5 years time to test the model then? or from the hindcast I did 2
> > years ago for that date?
> >
>
> How would you distinguish this hindcast from one done by someone else? or
> with a different model,? or ???? that all has to be elsewhere in the
> metadata somewhere -- none of it has anything to do with the time
> coordinate variable, nor is any of is part of the standard name.
>
> I think of it this way -- as this is my use case:
>
> I want the standard names, coordinate variables, etc to be the information
> I need to use these model results to drive my oil spill model. In that
> case, whether I'm driving it with a forecast or a hindcast, or when it was
> done, or what model it was done with, is all irrelevant. My code does the
> exact same thing with all of those.
>
> HTH,
>
> -Chris
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chris.Barker at noaa.gov
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Oct 25 2017 - 09:57:18 BST
