[netcdfgroup] Failure to handle GDS server-side analysis URL with netcdf 4.3.2

Dear Experts,
I am trying to do some server-side analysis via opendap with GDS, here is my 
analysis URL (zonal average of 500mb temperature): 

http://monsoondata.org:9090/dods/_expr_{gfs2/gfs.2014061000}{ave(t,lon=0,lon=360)}{0:0,-90:90,500:500,10jun2014:10jun2014}

An ncdump of this URL works just fine with version 4.2.1.1, but I get this 
error when using 4.3.2:

netcdf gfs {
dimensions:
        lat = 361 ;
        lev = 1 ;
        lon = 1 ;
        time = 1 ;
variables:
        double time(time) ;
                time:grads_dim = "t" ;
                time:grads_mapping = "linear" ;
                time:grads_size = "1" ;
                time:grads_min = "00z10jun2014" ;
                time:grads_step = "1hr" ;
                time:units = "days since 1-1-1 00:00:0.0" ;
                time:long_name = "time" ;
                time:minimum = "00z10jun2014" ;
                time:maximum = "00z10jun2014" ;
        double lev(lev) ;
                lev:grads_dim = "z" ;
                lev:grads_mapping = "linear" ;
                lev:units = "millibar" ;
                lev:long_name = "altitude" ;
                lev:minimum = 500. ;
                lev:maximum = 500. ;
        double lat(lat) ;
                lat:grads_dim = "y" ;
                lat:grads_mapping = "linear" ;
                lat:grads_size = "361" ;
                lat:units = "degrees_north" ;
                lat:long_name = "latitude" ;
                lat:minimum = -90. ;
                lat:maximum = 90. ;
                lat:resolution = 0.5f ;
        double lon(lon) ;
                lon:grads_dim = "x" ;
                lon:grads_mapping = "linear" ;
                lon:grads_size = "1" ;
                lon:units = "degrees_east" ;
                lon:long_name = "longitude" ;
                lon:minimum = 0. ;
                lon:maximum = 0. ;
        float result(time, lev, lat, lon) ;
                result:_FillValue = -9.99e+08f ;
                result:missing_value = -9.99e+08f ;
                result:long_name = "result of expression " ;

// global attributes:
                :title = "shorthand: /_exprcache_14024138664050  expression: 
ave(t,lon=0,lon=360)  source datasets: /gfs2/gfs.2014061000" ;
                :Conventions = "COARDS\n",
                        "GrADS" ;
                :dataType = "Grid" ;
                :history = "Tue Jun 10 11:24:26 EDT 2014 : imported by GrADS 
Data Server 2.0" ;
data:

syntax error, unexpected WORD_STRING, expecting WORD_WORD
context: Error { code = 0; message = "subset requests must include a constraint 
expression"^;};
NetCDF: Malformed or inaccessible DAP DATADDS
Location: file vardata.c; line 479


The error message "subset requests must include a constraint expression" comes 
from the GDS code that is examining the client request in the context of 
providing data subset in binary format. (Note that the error doesn't come until 
ncdump tries to get data.) Here is the java code snippet relevant to the 
constraint expression (CE):

        if (clientRequest.getCE() == null) {
            throw new ModuleException
                (this, "subset requests must include a constraint expression");
        }

The 'clientRequest' is what led me to suspect that this was a problem with the 
netcdf library built into the client. I know this is not a new GDS error, since 
the GDS code hasn't been changed in years. Is there something specific that 
changed in netcdf 4.3.2 related to constraint expressions or URL syntax? 

An ncdump of the URL without the analysis expression 
(http://monsoondata.org:9090/dods/gfs2/gfs.2014061000) works just fine with 
both netcdf versions, dumping metdata and data without error. 

--Jennifer





--
Jennifer M. Adams
Center for Ocean-Land-Atmosphere Studies (COLA)
111 Research Hall, Mail Stop 2B3
George Mason University
4400 University Drive
Fairfax, VA 22030 





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