> Lansing, > > It looks like you are using ToolsUI 4.2, not ToolsUI 4.3. In toolsUI > 4.2, you see one variable, but the times are wrong. In 4.3, you see > two variables with correct times, but we want one variable with > correct time! > > Try this: > http://www.unidata.ucar.edu/software/netcdf-java/v4.3/webstart/netCDFtools.jnlp > > On Mon, Jun 11, 2012 at 1:10 PM, Unidata netCDF Java Support > <address@hidden> wrote: > >> NetCDF-Java folks: > >> > >> There appears to be a bug in the GRIB2 decoding problem using > >> NetCDF-Java 4.3 on some of the surface pressure data we got from > >> http://rda.ucar.edu/pub/cfsr.html > >> > >> This data is supposed to have a single variable (pressure) with > >> uniform hourly sampling, but when we bring it up in NetCDF 4.3 tools, > >> we see two variables instead of one, with the 1st having a uniform > >> time base of 6 hours (0,6,12), and the 2nd having a non-uniform time > >> base that fills in the rest of the hourly data Â(1,2,3,4,5 > >> 7,8,9,10,11 Â13,14...) > >> > >> Screenshot: http://screencast.com/t/DWEgKMfy > >> > >> I put a sample file here: > >> http://geoport.whoi.edu/thredds/catalog/usgs/data1/rsignell/test/catalog.html?dataset=usgs/data1/rsignell/test/pressfc.gdas.199801.grb2 > >> > >> Thanks, > >> Rich > >> -- > >> Dr. Richard P. SignellÂÂ (508) 457-2229 > >> USGS, 384 Woods Hole Rd. > >> Woods Hole, MA 02543-1598 > >> > >> > > Hello Rich, > > > > I'm not sure what's going on, but I tried your file and saw only one > > variable reported. ÂI've attached a screenshot from NetCDF-Java ToolsUI. > > ÂMaybe I'm missing something obvious here? > > > > Regards, > > ÂLansing Madry > > ÂUnidata > > ÂBoulder, Colorado > > > > Ticket Details > > =================== > > Ticket ID: PYP-475421 > > Department: Support netCDF Java > > Priority: Normal > > Status: Open > > > > -- > Dr. Richard P. SignellÂÂ (508) 457-2229 > USGS, 384 Woods Hole Rd. > Woods Hole, MA 02543-1598 > > Rich, Thanks for educating me on 4.2 vs. 4.3 -- details, details! I dug a little deeper to see what is going on with the data in the file you sent. It looks like, at the byte level, there are some differences that 4.2 conveniently ignored and 4.3 notices. Specifically, if you look at the file in the iosp/GRIB2/GRIB2Collection tab, you'll notice that two variables seem to show up, with separate GDS hash codes. In that view, if you look down to the Grib2GridDefinitionSection, highlight a row, right-click on the row, and select "Show GDS", you'll see the information for Lo2 differs for the two "different" variables: Lo2 - longitude of last grid point == 359687000 Lo2 - longitude of last grid point == 359688000 This is really a defect in how the data was written out - perhaps a rounding error somewhere, or some other loss of precision. In the meantime, you can "correct" the issue using a bit of NcML to change the GDS hashcode. Details are here: http://www.unidata.ucar.edu/software/netcdf-java/formats/GribFiles.html and I've tried this bit of NcML and found it to work in this case: <?xml version="1.0" encoding="UTF-8"?> <netcdf xmlns="http://www.unidata.ucar.edu/namespaces/netcdf/ncml-2.2" location="C:/Users/madry/rsignell/pressfc.gdas.199801.grb2"> <iospParam> <gdsHash from="1450192070" to="1450218978"/> </iospParam> </netcdf> However, you will need to delete the associated .ncx file before opening this NcML file in the toolsUI-4.3 viewer. Let me know if this doesn't work for you, and I'll take another crack at it. Cheers, Lansing Ticket Details =================== Ticket ID: PYP-475421 Department: Support netCDF Java Priority: Normal Status: Open
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.