[Go-essp-tech] DRS question - temporal subset

martin.juckes at stfc.ac.uk martin.juckes at stfc.ac.uk
Thu Feb 9 06:53:32 MST 2012


Hello Estani,

I believe the intention of the parenthesis was to show how to deal with time instants (N1) and time periods (N1-N2) -- but I agree that this is not exactly what is said. The product assignment code is written on the assumption that both start and end times are in the filename, so it will not work for your data. 

I'm not sure about the best way forward -- I've not encountered any files like this,

cheers,
Martin
________________________________________
From: go-essp-tech-bounces at ucar.edu [go-essp-tech-bounces at ucar.edu] on behalf of Estanislao Gonzalez [gonzalez at dkrz.de]
Sent: 09 February 2012 12:30
To: Pascoe, Stephen (STFC,RAL,RALSP)
Cc: legutke at dkrz.de; go-essp-tech at ucar.edu
Subject: Re: [Go-essp-tech] DRS question - temporal subset

Sure,

trans.filename_to_drs('clmcalipso_cf3hr_MPI-ESM-LR_amip_r1i1p1_200810221030.nc')
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File
"/usr/local/cdat/lib/python2.6/site-packages/drslib-0.3.0a3-py2.6.egg/drslib/translate.py",
line 413, in filename_to_drs
     t.filename_to_drs(context)
   File
"/usr/local/cdat/lib/python2.6/site-packages/drslib-0.3.0a3-py2.6.egg/drslib/translate.py",
line 355, in filename_to_drs
     context.drs.subset = (_to_date(n1), _to_date(n2), clim)
   File
"/usr/local/cdat/lib/python2.6/site-packages/drslib-0.3.0a3-py2.6.egg/drslib/translate.py",
line 503, in _to_date
     mo = re.match(r'(\d{4})(\d{2})?(\d{2})?(\d{2})?(\d{2})?', date_str)
   File "/usr/local/cdat/lib/python2.6/re.py", line 137, in match
     return _compile(pattern, flags).match(string)
TypeError: expected string or buffer


But I'm more concern with the question of how should it be. Missing that
info will cause that in some particular cases you can't infer the end
date, and thus the start date of the next junk, without knowing the
calender type. If you need to get the file to read the calender type and
*then* infer the name, the usefulness of having a naming scheme would be
diminished.

As always I think we should comply with whatever rules and guidelines we
have, as a computer scientist I can't help but seeing the benefits of
homogeneity and the burden caused by exceptions.
That's why my question is: how should it be? I'm not sure I'm
interpreting the documentation properly.

Thanks,
Estani

Am 09.02.2012 13:14, schrieb stephen.pascoe at stfc.ac.uk:
> I think drslib will cope -- if not it's a bug -- but the product deduction code often needs both time bounds.
>
> Can you send me the error message.
>
> Thanks,
> Stephen.
>
> ---
> Stephen Pascoe  +44 (0)1235 445980
> Centre of Environmental Data Archival
> STFC Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX, UK
>
>
> -----Original Message-----
> From: go-essp-tech-bounces at ucar.edu [mailto:go-essp-tech-bounces at ucar.edu] On Behalf Of Estanislao Gonzalez
> Sent: 09 February 2012 11:06
> To: go-essp-tech at ucar.edu
> Cc: Stephanie Legutke
> Subject: [Go-essp-tech] DRS question - temporal subset
>
> Hi all,
>
> This is what the DRS reference says:
> "Temporal Subsets: Time instants and periods (N1(-N2))
>
> Time instants and periods will be represented by
> ‘yyyy[mm[dd[hh][mm]]][-clim]’, where ‘yyyy’,
> ‘mm’, ‘dd’, ‘hh’ ‘mm’ are integer year, month, day, hour, and minute,
> respectively, and enough
> (and just enough) of the suffixes should be added to unambiguously
> resolve the interval between
> time-samples contained in the file or virtual file URL. (For example,
> monthly mean data would
> include “mm”, but not “dd”, “hh”, or “mm”; “subhr” data would include
> all suffixes.) The
> optional “-clim” is appended when the file contains a climatology. For
> example, a file with
> sampling frequency of “mo” and the time designation 196001-198912-clim
> represents the
> monthly mean climatology (12 time values) computed for the period
> extending from 1/1960-
> 12/1989. Note that the DRS does not explicitly specify the calendar type
> (e.g., Julian,
> Gregorian), but the calendar will be indicated by one of the attributes
> in each netCDF file."[1]
>
>   From the title I infer that only the start point is required as part of
> the temporal subset, though the text speaks about "enough information to
> unambiguously resolve the interval between
> time-samples".
>
> The problem is that I get 3hr and subhr data with only the starting
> time-stamp, the drslib cannot cope with this.
> Should the drslib be adapted to accept that case or all files renamed?
>
> What about the rest of the system? Have anyone already tried publishing
> such files? Make sense?
> And what was the intention with the parenthesis in the Temporal Subsets
> title?
>
> Thanks,
> Estani
>
> [1] - http://cmip-pcmdi.llnl.gov/cmip5/docs/cmip5_data_reference_syntax.pdf
>


--
Estanislao Gonzalez

Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany

Phone:   +49 (40) 46 00 94-126
E-Mail:  gonzalez at dkrz.de

_______________________________________________
GO-ESSP-TECH mailing list
GO-ESSP-TECH at ucar.edu
http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
-- 
Scanned by iCritical.


More information about the GO-ESSP-TECH mailing list