Re: ECMWF ds117.1 data reading

Dennis,
Thanks a lot for the effort to clarify this question for me and for the
helping sample code!

But clarify this line for me if you will.
in line 60: "T_S2N = shsgC(TC(nt,kl,:,:,:), mlon) ; synthesize [S->N] "

the coefficients for TC is in descending order if I understood correctly
based on the summary given inside the GRIB data file while shsgC seems to
take only coefficients in ascending order according to the online
documents.

  TL

On Wed, 30 May 2007, Dennis Shea wrote:

> Tianle Yuan wrote:
>> Hi, Folks
>>
>> I need to read and convert temperature and specific humidity from the ERA40
>> ds.117.1 data set. There was a nice message on how to convert the 117.0
>> data by Dennis Shea:
>>
>> http://www.ncl.ucar.edu/Support/talk_archives/2006/0690.html
>>
>> It used the function 'g2fsh_Wrap' which requeires that latitude is in
>> ascending order while the data in ds117.1 is organized in descending
>> latitude order. Does it really matter?
>>
>> if so does a simple reverse of the data solve the problem?
>>
>> Thanks.
>>
>> TL
>> _______________________________________________
> Hello,
>
> I had an NCL script that reads the ERA40 data and created
> a netCDF file where the data go North-to-South. I modified it
> slightly from the original.
>
> http://www.cgd.ucar.edu/~shea/ds1171.ncl
>
> [1]
> Note Q on the original file is in N->S order and is 4-dimensional.
>
> Q_GDS4_ISBL(initial_time0_hours, lv_ISBL1, g4_lat_2, g4_lon_3)
>
> [2]
> T is 5D because the 'real_imaginary' spectral coef represent an extra
> dimension.
>
> T_GDS50_ISBL(initial_time0_hours, lv_ISBL1, real_imaginary, g50_lat_5,
> g50_lon_6)
>
> [3]
> NCL use spherepack ( a fortran library developed here at NCAR ).
> The shsgC synthesis function expects the coef to have been generated
> by spherepack. It turns out that the ECMWF spectral coef, when input
> to the spherepack synthesis functions generate data that are S->N.
> These should be reordered to match Q ... hence the reorder below.
>
> T_S2N = shsgC(TC(nt,kl,:,:,:), mlon) ; synthesize [S->N]
> T(nt,kl,:,:) = T_S2N(::-1,:) ; reorder [N->S}
> [4]
> Because the data variables are rather large
>
> T_GDS4_ISBL(124,23,2,160,160) ==> T(124,23,160,320)
>
> I decided to synthesize in a loop to minimize memory. [Spherepack has
> many temporary arrays.] This results in slower execution.
>
> [5]
> I added a very simple plot code.
>
>
> ====
>
> The separate issue of regridding via (say) g2fsh.
>
> NCL's ability to read/synthesize GRIB [both GRIB and the newer GRIB2]
> means that intermediate files need *not* be created. (The reason for
> generating
> the netCDF was so that it could be read by someon's IDL code.) You
> can take the ds1171.ncl code and remove the netCDF and add regridding
> as you desire.
>
> OK ... your question about S-N ordering "Does it really matter? "
> Well, there are historical reasons for the following answers
>
> [a] No .... for g2fsh
> [b] Yes .... for g2fsh_Wrap
> This is because the _Wrap functions create coordinate arrays.
> These are created using functions which generate latitudes that run S->N
> [c] simple code to demonstrate this
> http://www.cgd.ucar.edu/~shea/ds1171.ncl_regrid
>
> Good luck
> D
>
_______________________________________________
ncl-talk mailing list
ncl-talk_at_ucar.edu
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Wed May 30 2007 - 18:43:59 MDT