[Go-essp-tech] CMOR DRS name

[Kettleborough, Jamie]

Hello Estani,

If your application needs reliable time spans from the file I think the best way to do this is to look at the time coordinate in the NetCDF file itself.  Its a bit more cumbersome than implying it from the file name; but should be the most reliable source of information.

I guess the case you are worried about at the moment is drslib deciding whether to put things in output1 or output2?

For what its worth, and from what I remember, when we saw this problem when submitting data, we waited for the 2.6 release of CMOR.

Don't the timeCoverage parts of the thredds catalogs also contain the time span of a file?  My guess is this comes from an interpretation of the time coordinate within the cf netcdf file(s) rather than the file naming convention.  So if you want example code of how to extract the information it may be somewhere in the software stack already.  (I don't know anything about this really - I'm just making educated guesses.  I'm sure someone on the list knows how thredds gets those timeCoverages though.)

Jamie
 
> -----Original Message-----
> From: go-essp-tech-bounces at ucar.edu 
> [mailto:go-essp-tech-bounces at ucar.edu] On Behalf Of Stéphane Senesi
> Sent: 24 August 2011 13:45
> To: go-essp-tech at ucar.edu
> Subject: Re: [Go-essp-tech] CMOR DRS name
> 
> Estanislao
> 
> The attachments may be relevant
> 
> S
> 
> Estanislao Gonzalez wrote, On 24/08/2011 13:32:
> > Hi all,
> >
> > I'm seeing a problem which apparently comes from a known 
> CMOR bug and 
> > would like to know how other institutions work around it.
> >
> > CMOR produced files with this name:
> > psl_6hrPlev_MPI-ESM-LR_amip_r1i1p1_1979010100-197912311800.nc
> >
> > the problem here is in the subset. As you can notice here, 
> the date is 
> > defined in two different resolutions:
> > 1979010100
> > 197912311800
> >
> > The DRS syntax say nothing about it:
> > 
> http://cmip-pcmdi.llnl.gov/cmip5/docs/cmip5_data_reference_syntax.pdf
> > Although this field is defined as:
> > yyyy[mm[dd[hh][mm]]][-clim]
> >
> > This definition is a little awkward as it allows to have 
> either hours, 
> > or minutes, or both or none at all. But I assume that for 
> some users 
> > that can be implied from the context.
> >
> > Have anyone already seen this? is there a bug already 
> documented? And 
> > how are tools handling it? (I know the drslib can't)
> >
> > Do you see any other problems here?
> >
> > Thanks,
> > Estani
> >
> >    
> 
> 
> --
> Stéphane Sénési
> Ingénieur - équipe Assemblage du Système Terre Centre 
> National de Recherches Météorologiques Groupe de Météorologie 
> à Grande Echelle et Climat
> 
> CNRM/GMGEC/ASTER
> 42 Av Coriolis
> F-31057 Toulouse Cedex 1
> 
> +33.5.61.07.99.31 (Fax :....9610)
> 
>