[gradsusr] Open GRIB Files over THREDDS Opendap Server

[William Daniel Scheftic]

The behavior seems to be intermittent.  I tried to open my larger ctl 
file with most of the variables.  First time it failed. Second time with 
no changes it opened fine.  I had another connection failure on a data 
request and then retried it with success.

I have noticed it's much slower to load the ctl file and plot the 
variables through this server.  The NCEP GDS server runs very fast for 
even larger data requests.  Does the THREDDS opendap server do the same 
work for splicing the data prior to sending it as GDS does?

I'll have to check with NCEI because I got an error with an xml dump 
when trying to plot the same variable in GrADS.

Also, I'm a little confused about how to extract levels from 
non-pressure data using the same ctl file.  Can I do this in my ctl file?
Storm_relative_helicity_height_above_ground_layer_136_Hour_AverageNanalysis=>hlcy0_1000m 
0 t,0,y,x ** 0 to 1 km storm rel. helicity
Storm_relative_helicity_height_above_ground_layer_136_Hour_AverageNanalysis=>hlcy0_3000m 
0 t,1,y,x ** 0 to 3 km storm rel. helicity
The vertical coordinate for this variable is:
  height_above_ground_layer = 500, 1500 ;

  height_above_ground_layer_bounds =
   1000, 0,
   3000, 0 ;



 > If my sample descriptor works just fine, then the problem is not with 
GrADS.  Using template strings with URLs is no problem. Just be aware 
that you’re doing I/O over the internet, and it may be slow. Use 
define/fwrite/sdfwrite to copy data you’re going to look at more than 
once to local memory/disk.
 >
 > Since ncdump dies midway through parsing the file, then I would check 
with tech support at NCEI. The netcdf errror message points to line 473 
from vardata.c, which contains the following library call:
 >
 >     NC_CHECK(nc_get_vara(ncid, varid, cor, edg, (void *)valp));
 >
 > Something is funky with that variable; the data owners should be able 
to track it down.
 > —Jennifer