This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> 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