> Generally, I don't like the idea of any changes in the layout of
operational products. There are often programs which make smart assumptions
to speed up processing of the data.
I understand, and its not a smart assumption to hardcode variable or
dimension names, its really a Very Bad Practice. NetCDF's strength is its
self-contained metadata.
The added difficulty here is that the data is in GRIB, and we have
intermediate software that constructs multidimensional variables and
coordinates from a collection of 2D objects whose semantics can be vague.
Version 4.5 of that software is yet another attempt to do that correctly
and for large collections. Its not possible to keep backwards compatibility
as an absolute priority.
And again, I understand well the problems of legacy code!
Regards
John
On Tue, Jun 24, 2014 at 11:39 AM, Heiko Klein <Heiko.Klein@xxxxxx> wrote:
> Hi John,
>
> thanks for the information. Generally, I don't like the idea of any
> changes in the layout of operational products. There are often programs
> which make smart assumptions to speed up processing of the data - which
> then suddenly fail.
>
> In the current case, we've been using the subsetter to get around
> 10variables from the GFS, and we have one program which assumes there is
> only 1 time-dimension named 'time' (hardcoded) in the file
> (legacy-assumption, derived from an older file-format). Most likely, there
> was always one of the 10 variables having the 'time'-dimension until last
> night.
>
> I guess, we can solve the dimension changes by a hack involving ncdump +
> grep + ncrename, until we find time to upgrade our program.
>
> Best regards,
>
> Heiko
>
>
> On 2014-06-24 19:09, John Caron wrote:
>
>> Hi Heiko:
>>
>> The names of the time dimensions are arbitrary and you cannot count on
>> which variable uses which time dimension. Im surprised you were able to
>> assume constant name even in the 4.3 version.
>>
>> You must use the coordinate variable that matches the dimension name
>> used by the variable, eg float timex(timex). You dont need the
>> netcdf-java coordinate system layer, that info is available in the
>> netcdf-C API and all languages that use it.
>>
>> John
>>
>>
>> On Tue, Jun 24, 2014 at 7:46 AM, Heiko Klein <Heiko.Klein@xxxxxx
>> <mailto:Heiko.Klein@xxxxxx>> wrote:
>>
>> Hi,
>>
>> we're using the GFS data from
>> http://thredds.ucar.edu/__thredds/catalog/grib/NCEP/GFS/
>> __Global_onedeg/catalog.html
>>
>> <http://thredds.ucar.edu/thredds/catalog/grib/NCEP/GFS/
>> Global_onedeg/catalog.html>
>>
>> We've been using it for several weeks now without problems, but the
>> data from 20140624_00 got suddenly very strange, in particularly,
>> the time-dimensions (time, time1, time2, time3) swapped, e.g.
>>
>> The time-dimension of u-component_of_wind_height___above_ground is
>> 0624_06: time2
>> 0624_00: time3
>> 0624_00 - threddsbackup.ucar.edu <http://threddsbackup.ucar.edu>:
>> time
>>
>>
>>
>> Since we are using some programs which are not aware of
>> coordinate-systems and don't detect time-dimensions automatically
>> (i.e. they are not netcdf-java based), these files are very
>> difficult for us to use. Is this a temporary problem on
>> thredds.ucar.edu <http://thredds.ucar.edu> due to the upgrade, or
>>
>> will the names of the time-dimension swap arbitrary in the future?
>>
>>
>> Best regards,
>>
>> Heiko Klein
>>
>> On 2014-06-13 17:57, John Caron wrote:
>>
>> As detailed in last weeks announcement, the TDS server at
>> http://thredds.ucar.edu/__thredds/
>>
>> <http://thredds.ucar.edu/thredds/> will be switching to use
>> version 4.5
>> on Monday, June 16.
>>
>> To help in the transition:
>>
>> 1) The new "release candidate" server is currently running at
>> http://threddsRC.ucar.edu/__thredds/
>> <http://threddsRC.ucar.edu/thredds/>
>> <http://threddsrc.ucar.edu/__thredds/
>>
>> <http://threddsrc.ucar.edu/thredds/>>.
>> Please take the time to test it and give us feedback sooner than
>> later.
>>
>> 2) The 4.3 server will continue to be available at
>> http://threddsBackup.ucar.edu/__thredds/
>> <http://threddsBackup.ucar.edu/thredds/>
>> <http://threddsbackup.ucar.__edu/thredds/
>>
>> <http://threddsbackup.ucar.edu/thredds/>> for at least a week
>> after the
>> switch, in case there are any mission critical issues that arise.
>>
>> 3) IDV users can use a special plugin that will automatically
>> remap
>> their bundles for testing purposes; there is also a plugin to
>> remap to
>> the threddsBackup server if issues arise. Both plugins can be
>> found in
>> the IDV plugin manager under the "Data Sources" category. For
>> information on how to use plugins in the IDV, please see
>> http://www.unidata.ucar.edu/__software/idv/docs/userguide/__
>> misc/Plugins.html
>>
>> <http://www.unidata.ucar.edu/software/idv/docs/userguide/
>> misc/Plugins.html>
>>
>> 4) If you have IDV bundles (.xidv) that you would like us to add
>> to the
>> IDV testing suite to help detect problems in the future, please
>> submit
>> at http://motherlode.ucar.edu/__repository/alias/TestMyBundle
>>
>> <http://motherlode.ucar.edu/repository/alias/TestMyBundle>
>>
>>
>> --
>> Dr. Heiko Klein Tel. + 47 22 96 32 58
>> <tel:%2B%2047%2022%2096%2032%2058>
>>
>> Development Section / IT Department Fax. + 47 22 69 63 55
>> <tel:%2B%2047%2022%2069%2063%2055>
>>
>> Norwegian Meteorological Institute http://www.met.no
>> P.O. Box 43 Blindern 0313 Oslo NORWAY
>>
>>
>>
> --
> Dr. Heiko Klein Tel. + 47 22 96 32 58
> Development Section / IT Department Fax. + 47 22 69 63 55
> Norwegian Meteorological Institute http://www.met.no
> P.O. Box 43 Blindern 0313 Oslo NORWAY
>
