[gradsusr] LON-LAT for European sector
Clark, Douglas B.
dbcl at ceh.ac.uk
Mon May 9 08:19:53 EDT 2011
Djordje,
I haven't used a GrADS-DODS server in recent years (shocking, I know) and so don't know quite how it works in detail...but it looks to me as if the command you give will extract the data and I assume that you then write it to the file RTmavglobal(1961-1990).grd using further GrADS commands (e.g. 'set gxout fwrite' then "display "). If so, I assume you can write a subset of the data by using 'set lon' or 'set x' before using "display". If the actual process you use to write the file is very different then, sorry, I don't know what to do.
(And I guess that your expression returns the same values regardless of whether you use 360 or 357.5 because in each case GrADS (or more likely the DODS server in this case....I told you I'm not sure of details!) decides that this covers the gridpoints at all longitudes.)
Doug
From: gradsusr-bounces at gradsusr.org [mailto:gradsusr-bounces at gradsusr.org] On Behalf Of Djordje Romanic
Sent: 09 May 2011 11:21
To: GrADS Users Forum
Subject: Re: [gradsusr] LON-LAT for European sector
Dear Doug,
Now I see... I made a slip during the calculation. Namely, I've used NCEP/NCAR reanalysis data to calculate relative topography, and to do that I've used the command:
***************************
sdfopen http://nomad1.ncep.noaa.gov:9090/dods/_expr_{reanalyses/reanalysis-1/6hr/pgb/pgb}{hgtprs(lev=500)-hgtprs(lev=1000)}{0<http://nomad1.ncep.noaa.gov:9090/dods/_expr_%7breanalyses/reanalysis-1/6hr/pgb/pgb%7d%7bhgtprs(lev=500)-hgtprs(lev=1000)%7d%7b0>:360,-90:90,1000:1000,00z1jan1961:00z1jan1991}
***************************
However, the longitude in the original file (on nomad server) goes only up to 357.5. BUT, even if I replace 360 with 357.5 in the above command I get the same result---WHY?
Dear Doug, since I have more than a month of work behind me and all of that work was done usung the above command (with lon=360) and the result is the same as it would be 357.5 instead of 360, but the difference is in writing the result in a file, is it possible to change something in the CTL file and to correct a mistake? You were right, if in the previous command is 357.5, than I am able to set lon from -30 to 60. Since eveything else is the same, except this ploting issue, please is it possible to correct that so that I don't have to do the same tremandeus work from the beginning?
Regards,
Djordje
2011/5/9 Clark, Douglas B. <dbcl at ceh.ac.uk<mailto:dbcl at ceh.ac.uk>>
Djordje,
I'm not sure, but I suspect that the problem might be related to the fact that the xdef entry in the ctl file appears to specify a grid that covers more than 360degrees of longitude, in that 145x2.5=362.5. So I think GrADS has failed to identify that the grid should be cyclic in longitude or just can't work out which data to use in the "overlap" area. I certainly couldn't get anything to plot across 0E when I hacked up an example, even when I tried a few standard "tricks".
(The fact that the grid is rather large in latitude too, >180deg, probably doesn't matter because there's no need for GrADS to wrap round in latitude. Also note that for a "basic" gridded data file, the t,z,y,x bit in the var line is not used, as far as I know - I tend to put "99" in there instead.)
IF you only had one time level in the data file (which only has a single variable on a single level in it), you might be able to change the xdef line to have nx=144 so that GrADS thinks it only has data for 360deg - BUT THAT WILL NOT work for your current example which has >1 time.
I think you'll probably have to trim the grid to 360deg before going into GrADS if you want to plot across 0E.
If the data file RTmavglobal(1961-1990).grd was written using fwrite to output a subset of a larger file, then I think you will be able to proceed by explicitly setting 'set x 1 144' before you write the file. Otherwise GrADS will likely have added an extra column of data because of how it normally sets up for a global grid.
Doug
From: gradsusr-bounces at gradsusr.org<mailto:gradsusr-bounces at gradsusr.org> [mailto:gradsusr-bounces at gradsusr.org<mailto:gradsusr-bounces at gradsusr.org>] On Behalf Of Djordje Romanic
Sent: 09 May 2011 08:54
To: GrADS Users Forum
Subject: [gradsusr] LON-LAT for European sector
Dear Users,
I have a *.grd file (relative topography data) covering the whole globe. His CTL file is as follows:
***************************************************************************
dset ^RTmavglobal(1961-1990).grd
undef 9.999e+20
xdef 145 linear 0 2.5
ydef 73 linear -90 2.5
zdef 1 levels 1000
tdef 43709 linear 0Z31jan1961 360mn
vars 1
RT 1 t,z,y,x **Relative topography 500/1000 [hPa]
endvars
**************************************************************************
The data on global map (LAT -90 90; LON 0 360) are attached (global.jpeg). Now, from the global file I want to extract the data for the European sector (longitude interval is from 30W to 60E and latitude interval is from 0 90N), but after the following commands:
***********************************************************************
set lon -30 60
set lat 0 90
d rt
************************************************************************
I get the image that does not have the data East of the 0 meridian(attached as file euro.jpeg).
Please, can someone help me with this issue? What is causing this?
Kind regards,
Djordje
--
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org<mailto:gradsusr at gradsusr.org>
http://gradsusr.org/mailman/listinfo/gradsusr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20110509/4ac0e308/attachment-0003.html
More information about the gradsusr
mailing list