Before going any further, a word about majority. Most netCDF utilities use row-major order, but MATLAB uses column-major order. This means that when MATLAB reads in a netCDF variable, the ordering of the data remains the same as it exists in the file, but now the 1st dimension varies the fastest. In row-major order application, the last dimension varies the fastest. When mexcdf first came on the scene (long before my time), applications that sat on top of mexcdf usually transposed the data upon output to keep the shape of the data looking as it does with C applications, i.e. if ncdump (the utility that comes with the netCDF source code) reports a variable with 10 rows and 5 columns, then mexcdf would read in the data (which would be 5x10), and then transpose it to make it 10 by 5. Since it's being transposed, the ordering of the data is not being preserved. That's just the way it worked before I got hold of the code.

This is all fine and well, but when data gets really really large, that transpose operation will cause a bigger and bigger performance hit. For this reason, SNCTOOLS allows you to control whether or not the transpose operation will happen, and the PRESERVE_FVD (for "preserve fastest varying dimension) preference is the key. For the rest of this tutorial, we'll assume that MATLAB will in fact be transposing.

Let's get back on track. In the prior example, we saw a dataset with three variables, lon, lat, and elevation. Let's retrieve the longitude, using nc_varget.m. The m-file is most simply used to get an entire variable as follows.

today = datestr(floor(now),'yyyymmdd'); 
url = ['http://motherlode.ucar.edu:8080/thredds/dodsC/satellite/CTP/SUPER-NATIONAL_1km/current/SUPER-NATIONAL_1km_CTP_',today,'_0000.gini'];                      
x = nc_varget ( url, 'x' );

x(1:5)

   1.0e+03 *

   -6.0960
   -6.0881
   -6.0801
   -6.0722
   -6.0642

Please, please do not go nuts with nc_varget.m and try to limit your opendap data retrievals to what you need. Trying to retrieve 50 GB of data will only earn you a heaping of scorn from the maintainers of the remote opendap data site.