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.
Nir, >Date: Fri, 5 Mar 2004 03:11:16 +0200 >From: address@hidden >Organization: ? >To: address@hidden >Subject: Re: 20040304: UDUNITS problem: time varaibles: data types > Keywords: 200403042037.i24KburV008355 The above message contained the following: > I followed your instructions, and got no more error message. Good! > However, I still couldn't get the CDFreader to read the NCEP files correctly. > > For the measurements taken from November 11 2003 it gives me > incorrect values in the file (see details below). > > I copied the part of the subroutine that is printing the results. > > I will appreciate any advise, > > Thank you very much, > > Nir. > > > if(ipack.eq.1)then > call ncvgt(inet,ivar,startl,countl,idata,icode) > call unpack(idata,x,xscale,xoff,miss,ilon,jlat) > else > call ncvgt(inet,ivar,startl,countl,x,icode) > endif > call ncvgt(inet,itimeid,nt,1,xtime,icode) > istart2(1)=nt > icount2(1)=1 > call ncvgt(inet,itimeid,istart2,icount2,xtime,iercode) > print *,iyear,imonth,iday,ihour > call udparse(unitstrin,xtime,iyear,imonth,iday,ihour) The "print" statement should be after the call to "udparse" because that routine sets the values of the "iyear", "imonth", "iday", and "ihour" variables. What are the types of the following variables: xtime, iyear, imonth, iday, ihour? What is the type of the netCDF variable corresponding to "itimeid"? What is the "udparse" routine? The routine in the UDUNITS package that converts DOUBPELPRECISION values to calendar and clock time is "utCalendar". > The print results, according for the same run on other computer, were suppose > to be > 2003 11 11 0600 > 2003 11 11 1200 > 2003 11 11 1800 > > and so on, but instead are: > > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 > 1 1 1 0 Regards, Steve Emmerson