This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Greg Fall <address@hidden> >Subject: Re: 980201: NetCDF problems w/Linux >Organization: University of Michigan >Keywords: 199802010159.SAA05810 netCDF Linux Greg, > > > Tried to build NetCDF today a few times on my Linux (kernel 2.0.32) > > > system. Started with version 3.4a, then tried 3.3.1, than 2.4.3. > > > > > > The build went fine in every case. However, whenever I tried to use > > > ncdump on one of my data files, I'd get errors. > > > > > > With versions 3.4a and 3.3.1, the error looks like this: > > > > > > bash % ./ncdump /mnt/zip/HRDI/ng_0094_v1_2.nc > > > ./ncdump: /mnt/zip/HRDI/ng_0094_v1_2.nc: Invalid argument This is weird, because none of the ncdump sources contain the string "Invalid argument" anywhere. I don't understand how this message could be coming from ncdump. The only explanation that seems consistent with this behavior is that the executable in that directory that is named "ncdump" is not our program, but instead some other program that has been renamed to "ncdump". > > After you built netCDF, did you run "make test" to see if it passed all > > the tests that come with the source distribution? In particular, did > > the ncdump test work? > > ncdump is fine, so I'm thinking there must be something wrong with my > data. I produced the files using IDL version 4.0.1b. I've enclosed one > and if you could try ncdumping it I'd like to know whether it's my libs or > the data. The error I get is now > > *** ncdump: ncopen failed on ng_0901_v1_2.nc The message above indicates that this is the old version of ncdump from the netCDF 2.4.3 distribution, since the error message from the 3.3.1 version is always more explicit about the causes of problems (e.g. "file not found"). The 2.4.3 ncdump just reports that ncopen() returned an error, but doesn't print the value of the error indicator, which would be more helpful. If you still have the 3.3.1 ncdump, what does it now report for this file? Could you possibly recompile the 2.4.3 ncdump, changing lines 279 through 282 from if (ncid == -1) { error("ncopen failed on %s", path); return; } to if (ncid == -1) { error("ncopen failed on %s, ncerr = %d, errno = %d", path, ncerr, errno); return; } and insert the statement extern int errno; somewhere before line 33 of ncdump.c? Recompiling this will give you a 2.4.3 ncdump with more explicit error messages in this case ... If the value of the ncerr flag is other than -1, it will be one of the list of error codes in netcdf.h that will help diagnose the problem. If the value of ncerr is -1, it will indicate a system error, such as "file not found", that can be diagnosed by from the value of the global "errno" flag and the errno.h include file. > As I mentioned in the other message, I have no problems reading these > files with either IDL or with ncdump on the (VMS) system on which they > were built. Thanks for your help. When I run ncdump (from a Sun or a Linux system) on the file you supplied, it looks fine: $ ncdump ng_0190_v1_2.nc netcdf ng_0190_v1_2 { dimensions: orbits = 15 ; observations = 1497 ; variables: short uars_day ; uars_day:long_name = "UARS day" ; uars_day:date = "19-Mar-1992" ; short obs_per_orbit(orbits) ; obs_per_orbit:long_name = "observations per orbit" ; float signal(observations) ; ... 3840, 3968, 266, -6241, 29915, 32309, -11330, 31983, -12808, -2209, 15599, -12872, -9379, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ; } --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu