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

Re: 2.3.2 vs. 2.4 netCDF question

> Keywords: 199604222201.AA01657
> From: address@hidden (John Sheldon)
> Subject: Re: missing_values

John,

I've gotten your last two messages and have a speculation about what is
going on, but I have to travel away from my computer this afternoon  and
won't be able to confirm the possible bug until next week, so I've asked
Steve Emmerson to see if we can duplicate the problem here, from the last
example you sent.

> Yesterday, I CC'd you on some mail I sent to Jeff Kuehn about a timing
> code which demonstrated the CP-time problem with pre-filling on our
> Unicos 8 C90 under 2.4.1.
> 
> Here's a modified version of that code that pretty simply demonstrates
> that netCDF is writing one rendition of "1.E35" to the "missing_value"
> attribute and another rendition to the data portion of the file.
> 
> I hope we can get to the bottom of these issues pretty soon.  I'm
> riding what appears to be the crest of a tidal wave of new netCDF users
> here at GFDL, and the fewer reefs I encounter, the better!

(As an aside, if you send support questions like this one to
 "address@hidden" rather than directly to me or Steve, they will
 get routed to someone who is definitely here rather than out sick or on
 vacation, so they may get answered more quickly.)
 
> =================================
>       PROGRAM TIME_PREFILL
>       
> C Test program to time netCDF "pre-filling" on Cray....
> C
> C Modified 4/26/96 to demonstrate Cray problem with inconsistent
> C  precision in writing FLOAT's to attributes vs. data...
>       
> #include "netcdf.inc"
> 
>       PARAMETER (NI=360, NJ=180, NK=40, NL=3)
>       DIMENSION ARR(NI,NJ,NK), ID_DIM(4), ISTART(4), ICOUNT(4)
> 
> 
>       SPVAL=1.E35
> 
>       DO K=1,NK
>          DO J=1,NJ
>           DO I=1,NI
>              ARR(I,J,K) = SPVAL
>           ENDDO
>        ENDDO
>       ENDDO
> 
>       CALL NCPOPT(NCVERBOS+NCFATAL) 
> 
>       NCID = NCCRE('time_prefill.nc', NCCLOB, IRET)
> 
>       ID_DIM(1) = NCDDEF(NCID, 'lon',  NI, IRET)
>       ID_DIM(2) = NCDDEF(NCID, 'lat',   NJ, IRET)
>       ID_DIM(3) = NCDDEF(NCID, 'sigma', NK, IRET)
>       ID_DIM(4) = NCDDEF(NCID, 'time',   0, IRET)
> 
>       IDV = NCVDEF(NCID, 'TEMP', NCFLOAT, 4, ID_DIM, IRET)
>       
>       CALL NCAPT(NCID, IDV, 'missing_value', NCFLOAT, 1, SPVAL,IRET)
> 
>       IFMODE = NCSFIL (NCID, NCNOFILL, IRET)
> c      IFMODE = NCSFIL (NCID, NCFILL, IRET)
> 
>       CALL NCENDF(NCID, IRET)
> 
>       ISTART(1)=1
>       ISTART(2)=1
>       ISTART(3)=1
>       ICOUNT(1)=NI
>       ICOUNT(2)=NJ
>       ICOUNT(3)=NK
>       ICOUNT(4)=1
> 
>       DO L=1,NL
>          PRINT *,'Writing out time level ',L
>          ISTART(4)=L
>        CALL NCVPT(NCID, 1, ISTART, ICOUNT, ARR, IRET)
>       ENDDO
>       
>       CALL NCCLOS(NCID)
> 
>       END
> 

Thanks for sending this example, which Steve will be trying out here.  

We think what may be happening in 2.4.1 is that the NCVPT (or ncvarput)
calls are using the CRAY-specific optimized xdr_floats() function to convert
between native floats and IEEE, whereas the calls to define attributes may
be using the unoptimized xdr_float() function to convert one float at a
time.  Since different methods may be used in these two cases, it seems
possible that the external representation of the same value may be different
for attribute than for a data value.  

If this is the case, it is definitely a bug that we'll want to fix, probably
by using the optimized xdr_floats() function consistenly for attributes as
well as variables.

Thanks again for being persistent about reporting this error.

--Russ