Re: [idvusers] [thredds] Update - Changes to thredds.ucar.edu

Sean-

On 4/3/14 11:27 AM, Sean Arms wrote:
Did you happen to create a custom variable renamer (varrenamer.xml)? As
far as I know, nothing in GribVariableRenamer or the variable renamer
xml file in the CDM has changed.

I do not have a custom variable renamer file. I just ran IDV in the debugger. When I point to TDS 4.3 (thredds.ucar.edu), it works. When I point to TDS 4.5 (thredds-dev.ucar.edu), it doesn't. It's a problem with both IDV 4.1 and IDV 5.0. At this line in GeoGridDataSource:

List<String> newName = gribRenamer.matchNcepNames(ds, name);

pointing at TDS 4.3 newName is a list of 1, pointing at TDS 4.5 gives a list of 3 possibilities. As far as I can see, both the listings of data from TDS 4.3 and TDS 4.5 have all 3 variables. I'll let you run in the debugger to probe this further. Since the lookup passes in the dataset name, I think the change of the dataset in 4.5 is such that it's not finding the right entry in grib2VarMap.xml:

4.3: GFS_Global_onedeg_20140403_1200.grib2
4.5: GFS_Global_onedeg_20140403_1200.grib2/GC

(note the trailing GC). If that is the case, it could be problematic for more bundles than just mine.

Thanks for the offer to bounce ideas off of you (especially since you
are not paid to do this). The idea I have is to include the variable
attribute "Grib_Variable_Id", which every variable has, into the bundle.
An example value of this would be value="VAR_0-3-5_L100", which is made
up of the grib parameter discipline, category, name, and level codes.

Are these always unique, i.e., does this capture all the parameter, level, accumulation time, etc info?

You could add these into the DataChoice properties Hashtable in doMakeDataChoices and then check for that in the GeoGridDataSource.findGridForDataChoice method. It would be nice to have the CDM be able to turn those into the appropriate variable name instead of having the IDV have to run through all the GeoGrid objects to find one that matches.

Another through is that we could add a method to the Variable object
that returns a unique id that would by default return the "name", but
could return an actual unique id, dependent on the data model being
dealt with (may be similar to Grib_Variable_Id for GRIB, variable name
for netcdf, etc.).

Again, these could be put in the hashtable of properties for the DataChoice.

Either of these would only be valid for new bundles once implemented.

Don

On 4/3/14, 8:35 AM, Don Murray (NOAA Affiliate) wrote:
John/Sean-

On 4/3/14 6:51 AM, John Caron wrote:

The variable names have not changed. The bundles will still work. We
are
fixing the ones that Darryl discovered had changed.

They have changed.  As I pointed out on Monday, in this bundle:

http://www.esrl.noaa.gov/psd/repository/entry/get/gfs-nh-sh.xidv?entryid=d178fe25-5bfd-40cf-930d-960adcbe3d30




the U and V wind variables have changed when pointed to 4.5 on
thredds-test.


I will track this down, but its probably that WMO or NCEP changed their
tables. sean has some ideas how to improve bundles to help with this
ongoing problem, but i dont know of a short term fix at the moment.

This bundle predates TDS version 4.3 and uses the GribVariableRenamer
API to lookup the corresponding name in the new grib package.  The
problem seems to be that GribVariableRenamer pointing to TDS 4.3 returns
one match for "U-component_of_wind" (i.e. u-component_of_wind_isobaric),
but in 4.5, it is returning multiple matches.  The variable name seems
not to have changed, but the response from GribVariableRenamer has.

Sean, if you want to bounce any ideas on how to improve the bundles, I'd
be happy to listen/help.

Don

--
Don Murray
NOAA/ESRL/PSD and CIRES
303-497-3596
http://www.esrl.noaa.gov/psd/people/don.murray/



  • 2014 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the idvusers archives: