Re: netCDF error:ncattput

> Organization: GFDL
> Keywords: 199403252133.AA09698

Hi John,

Sorry to take so long replying to your question but I was on vacation when
it arrived, and it has just finally come to my attention.

> I am having a problem using netCDF on our YMP.  I am using netCDF 
> version 2.3.2 to generate a simple file containing 2 derived variables
> for each of several history files from a model. I put this in a loop
> over the history files and it works fine for the first two but always
> bombs on the third with :
> 
> ncattput: NC_new_array: No such file or directory
> 
> I have narrowed it down to the specific "CALL NCAPT" and eliminated the 
> call, but it eventually bombs somewhere else.  Setting NCPOPT to 
> NCVERBOS (ie, not fatal) eventually leads to an operand range error.
> In compiling my code, I've tried indefinite initialization, bounds 
> checking, "flint", and whatever else I could think of, to no avail.
> 
> I realize I'm not giving you enough to assess my detailed problem here.
> Before I went to all the trouble of putting together a bomb-able
> package, I thought I'd at least check with you to see if this is a 
> "common" problem, or if you had any ideas I could check out on my own
> without dragging you down into it.

I can't recall ever seeing a problem with these symptoms before.  I've
looked at the source code for NC_new_array in netcdf/libsrc/array.c, and it
appears to me that the only error that can occur in that function that would
cause a message containing the string "NC_new_array" is if the memory
allocation call to malloc() failed.  This might happen if you are
inadvertantly requesting a huge amount of memory, for example if a
floating-point value is passed in instead of an integer to NC_new_array().
The error message "No such file or directory" makes no sense in this
context, but it's possible the global error number flag was set and not
cleared in a previous attempt to open a non-existent file.

A possible cause for the problem would be calling NCAPT with a huge value of
ATTLEN, the attribute length.  Or perhaps a previous problem in the program
has caused the location that is supposed to contain the ATTLEN parameter
to be overwritten with a floating-point value.

If you can demonstrate the problem with a small test program, we could try
to diagnose it, although we don't have easy access to a Cray YMP.

__________________________________________________________________________
                      
Russ Rew                                              UCAR Unidata Program
address@hidden                                        P.O. Box 3000
(303)497-8645                                 Boulder, Colorado 80307-3000