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

Re: Problem with 3.3a lib (CRAY T90); What is a netCDF id?

> > In netcdf-3,
> > the number you get back from NCCRE or NCOPN is the file descriptor
> > returned from the underlying ncio_open(). On most systems, it is
> > the return from the open() system call, so 3 makes sense here.
> > (0==stdin, 1== stdout, 2==stderr are already open.)
> > On the CRAY, it should be the return from ffopens().
>
> Wait - this is quite different from version 2.4, no?  I have come to
> rely on these ID's being from 0 to (MAXNCOP-1)!  I can (and maybe will
> have to) recode a bunch of stuff to get around this, but why change
> it?  Now, with 3.3, the ID's that come back are platform dependent -
> this doesn't seem quite "right".

It is different from netcdf-2, but not different from the netcdf spec.
The netcdf-2 Users Guide (Chapter 5, paragraph 2) says that a netCDF id
small nonnegative integer, ... much like a file descriptor, ...
unique for each call to NCOPN or NCCRE. We never say it starts at 0,
increasing monotonically or anything like that. In the following sense,
netcdf-3 meets the above spec better than what we did before:
What could be more "like a file descriptor" than a file descriptor?

> (Just for clarity, the above problems were using 3.3a on the T90, and
> 3.3 on the SGI.)

This behavior is the same anyway.

For the cray, the underlying "descriptor" is what is returned from
ffio_open. Here is what they say about that

     The ffopen function returns an integer.  Although it is not a file
     descriptor, it is used in much the same way when passed to the other
     functions such as ffread, ffwrite, or ffclose.

E.G., like the netcdf id, it is an opaque handle.
We probably should eliminate the adjective "small" from
our netcdf id spec, since they say nothing about return from ffio_open
being "small".

>
> > The T90, the problems you are having indicate some
> > problem with the Fortran to C bridge.
> > You might try going through fortran/cfortran.h and
> > substuting 1 for all occurances of _CRAYT3E.
>
> In this case, I presume we are talking about version 3.3.1a that I
> brought over from the T3E.  I made the change you suggested. (Well,
> not exactly - the "defined(1)" made the compiler gag, but it wasn't
> hard to figure out what the outcome was supposed to be and comment out
> what wasn't supposed to take place.)  However, this didn't change
> anything:  same link problems, same ftest problems.
>
> Maybe I should just wait till things eventually get sorted out??
> (I'm not in that big of a rush...)

Thanks for trying this. It saved me some time.

Rather than duplicating effort, can you set up your netcdf-3.3.1a
directories on t90 so I can write there? I'll poke around and
and see if I can figure out what is hosing up.

-glenn