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

Re: 19980903: netcdf-3.4 problem on IRIX 6.4

>To: address@hidden
>From: Christine Molling <address@hidden>
>Subject: netcdf-3.4 problem on IRIX 6.4
>Organization: University of Wisconsin Madison
>Keywords: 199809032100.PAA01229
>
> Dear Support,
>
> It's a long story, so let me begin at the beginning.
>
> When I installed netcdf-3.3 on my SGI's (both IRIX 6.2 and IRIX 6.4,
> both 32 and 64 bit machines), everything was fine until I did a diff
> between two binary files I was comparing in a test.  It turns out that
> the same FORTRAN (mipspro 7.2) program compiled on a machine running
> IRIX 6.2 (both a 32 bit machine and a 64 bit machine, both Indigo 2's)
> produced a file exactly half the size of the files produced on a machine
> running IRIX 6.4 (Origin 200, 32 bit).  Both files were readable on the
> other platform and by other software, so I didn't do anything about it.
> I had more immediate things to do.
>
> Today I decided to revisit that problem by testing if netcdf-3.4 had the
> same weirdness.  So I compiled netcdf-3.4 on my IRIX 6.4 machine
> (compiled fine, make test passed all tests) and reran the program.
> Failure!
>
> The program failed to create a file properly, however, I didn't get any
> error messages from the netcdf interface until I tried to write data
> into a variable.  The create-a-file phase did not report error; the
> create-a-variable phase did not report error; the put-data phase did,
> with the complaint that the file was not a netcdf file.
>
> Output to the screen from my program:
>  working on time step =            1
>     1.000000       1.000000
>  Warning in writevar
>  Not a netCDF
> file
>  Error in writevar
>  Not a netCDF
> id
>  Some error in writevar for 1st file
>
> When I look at the pseudo-netcdf file, it is very small (32 bytes
> instead of 4906) and has nothing but a few control characters in it.
>
> So: is it my program or is it netcdf-3.4 on IRIX?
> (I did not yet test it on IRIX 6.2 - I'm working on that.)
>
> If you have time to help me solve the problems...
>
> Please get from my anonymous ftp site (alpine.meteor.wisc.edu) the file
> pub/iespkg.tar.Z and follow the directions in README (this just says how
> to compile and run the program).  Test this program on a non-SGI with
> netcdf-3.4 as well as an SGI with netcdf-3.4.  This may indicate whether
> it is the program or the netcdf library which is to blame.
>
> If the program works:  what size are the output files? Are they the same
> for both platforms?
> If the program fails:  did it fail on all platforms?  When does the
> program report error messages?
>
> Thank you very much for your help.
> --
> Christine C. Molling          IES Center for Climatic Research
> address@hidden        Climate, People, and Environment Program
> (608) 262-4775                        University of Wisconsin - Madison

Christine:

I haven't traced out your code fully, but I have been able to reproduce
the problem here. Your basic problem is that you are creating the files
with NF_CREATE and then opening them again with NF_OPEN, without an
intervening call to NF_CLOSE or NF_SYNC.
So, your program has two active netcdf handles for each of the two netcdfs
it deals with.

I can't say why it works -n64 but not -o32 or -n32.

I suggest that
EITHER
subroutine 'inifile' & 'inifilec' close their
netcdfs before 'writevar' & 'readvar' open them ...
OR
You figure out some way to pass the netcdf id's around so you don't
have to re-open the file.

There some other, tricker things one could do instead, but I don't think they
are justified for this program. You can have multiple descriptors open at the
same time for the same netcdf and have them have consistant views of
file state by judicious use of NF_SYNC or by using the NF_SHARE flag to
NF_OPEN and NF_CREATE.

One thing that may be confusing you is the difference in length of files
when compiled -32 or -n64. In netcdf-3 (unless NF_SHARE is in force), the
file size gets rounded up to a natural system buffer size. Apparently this
buffer size is different in the different compilation environments. Don't
worry about it. If you do an octal dump ('od') you will see that the files
have the same content up to some point, and from then on they are zero filled.

-glenn