[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 980201: NetCDF problems w/Linux

>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