[ncl-talk] dimension changed in ncl definition different ctl file's description

David Brown dbrown at ucar.edu
Mon Mar 16 17:02:40 MDT 2015


Please in the future include ncl-talk in any replies. Thank you.

Well I do not know that much about GrADS, but just quickly looking at their
documentation (http://iges.org/grads/gadoc/variableformats.html) , I can
see they say that

"The default sequence goes in the following order starting from the fastest
varying dimension to the slowest varying dimension: longitude (X), latitude
(Y), vertical level (Z), variable (VAR), time (T)."

So, keeping in mind that they speak in Fortran terms where the
fastest-dimension is listed first, whereas NCL is the opposite, this means
to me that all the variables for one time step are written, then all
variables for the next time step, and so on. Other text on this page
suggests that your file follows the "default sequence", but you may want to
verify that.

We have already determined that a single record in this file covers the lat
and lon dimensions. Presumably all records are the same size.
So if you want, for example, to just read the u variable for all
time-steps,  you would need to elaborate the code I suggested to you in the
last message with another loop for the time dimension and you would need to
skip over all the records for the other variables after reading u for a
single timestep.

nvars_with_levels = 12
nsurface_vars = 34
U = new((/ntimes.nlev,nlat,nlon/), float)
recnum = 0
do j = 0, ntimes -1
    do i = 0, nlev -1
       U(j,i,:,:) = fbinrecread(fili,recnum, (/nlat,nlon/))
       recnum = recnum + 1
    end do
    recnum = recnum + nlev * (nvars_with_levels - 1) + nsurface_vars   ; U
has already been handled so there is one less var with levels
end do

This is not tested obviously since I do not have your file, but something
similar should work. And the same principles would apply for reading other
variables in the file.
 -dave



On Fri, Mar 13, 2015 at 9:35 PM, dyjbean soybean <dyjbean at gmail.com> wrote:

> hi,David
>   thanks for you explanation, but the time dimension described in ctl file
> show it has 21 times, which can be represented in grads as follows,
>    [image: 内嵌图片 1]
>
> the responding command shows as the below:
>   [image: 内嵌图片 2]
>
> according to the above figure, i think the U component should be 4D not
> 3D, i have used you code nlev*nlat*nlon, which can run in ncl, but i cannot
> discern which time it represents.
>
> but i'm confused how to write the correct code to read the 4D variables in
> data with ncl including time*level*lat*lon
>
>
>
>
> 2015-03-14 4:12 GMT+08:00 David Brown <dbrown at ucar.edu>:
>
>> Have you read the applications page on handling GrADS data
>> (http://www.ncl.ucar.edu/Applications/grads.shtml)? The Fortran
>> records in the file contain only a single lat/lon slice of the data.
>> You will need to read multiple records in a loop to get all the U
>> data.
>>
>> If you look at the sample script on the web page, you will see that
>> you need to preallocate the variable to the size of the variable you
>> are expecting and then read the data in a loop. I don't know for sure
>> how GrADS binary data files are organized, and I am not sure how the
>> time dimension is being handled: but based on the fact that each
>> variable has a 0 in its specification I am guessing that only one time
>> step is actually in the file even though it gives the time dimension
>> as 21. Assuming that all the U data comes first you could read it
>> using something like this:
>>
>> nlat = 180
>> nlon = 360
>> nlev = 29
>>
>> U = new((/nlev,nlat,nlon/), float)
>> do i = 0, nlev -1
>>    U(i,:,:) = fbinrecread(fili,i, (/nlat,nlon/))
>> end do
>>
>> There is a useful function, fbinnumrec
>> (http://www.ncl.ucar.edu/Document/Functions/Built-in/fbinnumrec.shtml),
>>  that will tell you the number of records in the file. It can be
>> helpful to know this number when trying to figure out layout of the
>> data in the file.
>>  -dave
>>
>>
>> On Fri, Mar 13, 2015 at 4:02 AM, dyjbean soybean <dyjbean at gmail.com>
>> wrote:
>> > hi, i met a strange problem between grads and ncl.
>> >
>> > the below is the ctl file for the data,
>> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >
>> > dset E:\lnw\postvar2010010100
>> > options sequential big_endian
>> > options sequential
>> > title post output from grapes
>> > undef -9.99E+33
>> > xdef  360 linear    0.0000    1.0000
>> > ydef  180 linear  -89.5000    1.0000
>> > zdef   29 levels
>> >  1000.000000
>> >  962.5000000
>> >  925.0000000
>> >  887.5000000
>> >  850.0000000
>> >  800.0000000
>> >  750.0000000
>> >  700.0000000
>> >  650.0000000
>> >  600.0000000
>> >  550.0000000
>> >  500.0000000
>> >  450.0000000
>> >  400.0000000
>> >  350.0000000
>> >  300.0000000
>> >  275.0000000
>> >  250.0000000
>> >  225.0000000
>> >  200.0000000
>> >  175.0000000
>> >  150.0000000
>> >  125.0000000
>> >  100.0000000
>> >  70.00000000
>> >  50.00000000
>> >  30.00000000
>> >  20.00000000
>> >  10.00000000
>> > tdef   21 linear 00z01JAN2010   360mn
>> > vars 46
>> > u 29 0 u_wind
>> > v 29 0 v_wind
>> > t 29 0 temperature
>> > h 29 0 geopotential height
>> > q2 29 0 specific humidity
>> > q3 29 0 specific humidity
>> > q4 29 0 specific humidity
>> > q5 29 0 specific humidity
>> > q6 29 0 specific humidity
>> > q7 29 0 specific humidity
>> > ozone 29 0 cloud fraction from microphy
>> > w 29 0 vertical wind
>> > ps 0 0 surface pressure
>> > psl 0 0 sea level pressure
>> > rainc 0 0 precipitation
>> > rainnc 0 0 precipitation
>> > ts 0 0 surface temperature
>> > glw 0 0 surface downward lw
>> > gsw 0 0 surface net sw
>> > glwu 0 0 surface upward lw
>> > tglwu 0 0 toa upward lw
>> > gclw 0 0 surface clear sky downward lw
>> > gclwu 0 0 surface clear sky upward lw
>> > tgclwu 0 0 toa clear sky upward lw
>> > gswu 0 0 surface upward sw
>> > tgsw 0 0 toa net sw
>> > tgswu 0 0 toa upward sw
>> > gcsw 0 0 surface clear sky net sw
>> > gcswu 0 0 surface clear sky upward sw
>> > tgcsw 0 0 toa clear sky net sw
>> > tgcswu 0 0 toa clear sky upward sw
>> > tcc 0 0 total cloud cover
>> > hcc 0 0 high cloud cover
>> > mcc 0 0 middle cloud cover
>> > lcc 0 0 low cloud cover
>> > tvw 0 0 column integrated qv
>> > tcw 0 0 column integrated qc
>> > tiw 0 0 column integrated qi
>> > hfx 0 0 sueface heat flux
>> > qfx 0 0 sueface vapour flux
>> > zs 0 0 terrain
>> > q2m 0 0 specific humidity at 2m
>> > t2m 0 0 temperature at 2m
>> > u10m 0 0 u wind at 10m
>> > v10m 0 0 v wind at 10m
>> > pblh 0 0 pbl height
>> > endvars
>> >
>> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >
>> > according to the above ctl file, we can find some variables 4D and
>> others
>> > 1D,
>> > so i gave the following code  in ncl for test:
>> >
>> > ++++++++++++++++++++++++++++++++++++++++
>> > fili="postvar2010010100"
>> > nlat=180
>> > mlon=360
>> > nlev=29
>> > ntim=21
>> >
>> > setfileoption("bin","ReadByteOrder","BigEndian")
>> > uwind=fbinrecread(fili,0,(/mlon,nlat,nlev,ntim/),"float")
>> >
>> > ++++++++++++++++++++++++++++++++++++++++
>> >
>> > but there come the following warning,
>> >
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> > warning:fbinrecread: size specified is less than record size, some data
>> will
>> > not be read
>> >
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >
>> > i changed its dimension description with "-1" instead of
>> > (/mlon,nlat,nlev,ntim/),as follows,
>> >
>> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> > uwind1=fbinrecread(fili,0,-1,"float")
>> > print(dimsizes(uwind1))
>> >
>> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >
>> > then, come to the following result,
>> >
>> > +++++++++++++++++++++++++++++++++
>> >  print(dimsizes(uu))
>> > (0)     64800
>> > +++++++++++++++++++++++++++++++++
>> >
>> > so i use the following code to read the first variable,
>> >
>> > ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> > uwind2=fbinrecread(fili,0,(/mlon,nlat/),"float")
>> > ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >
>> > there is no warning appeared.
>> >
>> >
>> > the above result shows that the first variable has the dimension
>> "mlon*nlat"
>> > not "mlon*nlat*nlev*ntim",which is so wierd.
>> > and i cannot distinguish which level and time the uwind2 represented.
>> >
>> > can somebody give me some advice about this difference between ctl
>> file's
>> > description and ncl realization?
>> >
>> > if i should add two cycle, like following,
>> >
>> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> > do i=0,ntim-1
>> >   do j=0,nlev-1
>> >      uwind=fbinrecread(fili,0,(/mlon,nlat/),"float")
>> >      vwind=fbinrecread(fili,1,(/mlon,nlat/),"float")
>> >      ttemp=fbinrecread(fili,2,(/mlon,nlat/),"float")
>> >
>> >      ....................
>> >      u10m=fbinrecread(fili,43,(/mlon,nlat/),"float")
>> >      v10m=fbinrecread(fili,44,(/mlon,nlat/),"float")
>> >      pblh=fbinrecread(fili,45,(/mlon,nlat/),"float")
>> >   end do
>> > end do
>> >
>> > +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >
>> >
>> > any help will be appreciated,thanks
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > ncl-talk mailing list
>> > List instructions, subscriber options, unsubscribe:
>> > http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>> >
>>
>
>
>
> --
> 通讯地址:北京市朝阳区大屯路9718信箱
>           中国科学院遥感应用研究所
> 邮编:100101
> 电话:010-64860422
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20150316/27771e26/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: com.JPG
Type: image/jpeg
Size: 42738 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20150316/27771e26/attachment.jpe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: time1-21.JPG
Type: image/jpeg
Size: 60236 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20150316/27771e26/attachment-0001.jpe 


More information about the ncl-talk mailing list