[gradsusr] problem in .ctl plot
Ismaila Diallo
ismailadiallo64 at yahoo.fr
Thu Dec 2 16:39:41 EST 2010
Hi everybody,
James T. Potemra, I've done your suggestion. That was changing the big_endian in
little_endian. but until i get the same plot with the same error.
The ctl script is:
set ^Dahra.dat
options little_endian
undef -1.e34
TITLE extract_obs_bignona
xdef 1 linear -17.5 1
ydef 1 linear 15.30 1
zdef 1 levels 1000
tdef 6575 Linear 01jan1991 1dy
VARS 1
tpr 0 99 precipitation (mm/jr)
endvars
Ps! i've attached again the plot.
Thanks in advance for all your help and suggestion
Ismaila
----- Original Message ----
From: "gradsusr-request at gradsusr.org" <gradsusr-request at gradsusr.org>
To: gradsusr at gradsusr.org
Sent: Thu, December 2, 2010 4:59:50 PM
Subject: gradsusr Digest, Vol 10, Issue 11
Send gradsusr mailing list submissions to
gradsusr at gradsusr.org
To subscribe or unsubscribe via the World Wide Web, visit
http://gradsusr.org/mailman/listinfo/gradsusr
or, via email, send a message with subject or body 'help' to
gradsusr-request at gradsusr.org
You can reach the person managing the list at
gradsusr-owner at gradsusr.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of gradsusr digest..."
Today's Topics:
1. Re: problem in .ctl plot (James T. Potemra)
2. Re: Plotting GFS_HD apcpsfc every 3 hours problems (Jeff Chabot)
3. Re: Memory Allocation Error When Using PRINTIM (Huddleston, John)
----------------------------------------------------------------------
Message: 1
Date: Thu, 02 Dec 2010 08:55:07 -1000
From: "James T. Potemra" <jimp at hawaii.edu>
Subject: Re: [gradsusr] problem in .ctl plot
To: GrADS Users Forum <gradsusr at gradsusr.org>
Message-ID: <4CF7EB8B.30805 at hawaii.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Ismaila:
Not knowing about you particular system, this looks like a
big_endian/little_endian
problem. In the ctl you specify big, but maybe it ought to be little?
Jim
Ismaila Diallo wrote:
> Dear,
>
> I've .ctl file of one station of precipitation in Senegal, when plotting the
> file, i get great value of rain. So you can see the attached file test.png and
> the script in test.ctl. Nevertheless i don't understand why the values of rain
> if so elevate compared the values in the original file.
>
> I attached the 2 files (script and plot).
>
> Sincerely
> Ismaila
>
>
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
------------------------------
Message: 2
Date: Thu, 2 Dec 2010 15:09:54 -0500
From: Jeff Chabot <jsc219 at gmail.com>
Subject: Re: [gradsusr] Plotting GFS_HD apcpsfc every 3 hours problems
To: gradsusr at gradsusr.org
Message-ID:
<AANLkTi=Xfv+LAGUxRexH4-m-p2hXqYCzqQfi+yXogHtm at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello Wesley,
Thanks for your explanation of the 3 hour versus 6 hour accumulation problem
with gfs_hd.
I tried your workaround, but it failed pretty quickly for me. I have never
used wgrib or wgrib2 and I searched on the internet for some documentation,
but I couldn't find much.
This is where if failed for me:
>sh
>[ -f IN.grb ] && rm IN.grb
>for f in (list of file from f03 to fNN)
sh: syntax error near unexpected token `('
Also, I believe that you would need to open the data file first, but I
couldn't get that to work either:
>wgrib
http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd20101202/gfs_hd_00z
could not open file:
http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd20101202/gfs_hd_00z
So, I am not sure how to use this workaround. Any further help would be
greatly appreciated.
Sincerely,
Jeff
Message: 4
> Date: Wed, 01 Dec 2010 09:21:02 -0500
> From: Wesley Ebisuzaki <Wesley.Ebisuzaki at noaa.gov>
> Subject: Re: [gradsusr] Plotting GFS_HD apcpsfc every 3 hours problems
> To: GrADS Users Forum <gradsusr at gradsusr.org>
> Message-ID: <4CF659CE.3050106 at noaa.gov>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Jeff,
>
> The "Joys of Compatibility" strikes again (old code expects 6 hour
> accumulations).
> Anyways there is a function in wgrib2 to make all the accumulations into
> 3 hour chunks.
>
> 1) put all the APCP records into one file (IN.grb) in order (f03 to
> fNN). Here is how to do it in sh.
>
> [ -f IN.grb ] && rm IN.grb
> for f in (list of file from f03 to fNN)
> do
> wgrib2 f -match ":APCP:" -append -grib IN.grb
> done
>
> IN.grb should contain the APCP from one forecast run starting from 3
> hour forecast to N hour forecast.
>
> 2) Run wgrib2 to normalize the records.
>
> wgrib2 IN.grb -match ":APCP:" -set_grib_type c1 -ncep_norm precip.grb
>
> Wesley Ebisuzaki
>
>
> Jeff Chabot wrote:
> > Hello GrADS Users,
> >
> > I am looking for help plotting 3 hr precip using gfs_hd (from
> > nomads.ncep.noaa.gov <http://nomads.ncep.noaa.gov>) every three
> > hours. I have it working fine using nam and gens. However, when I
> > plot apcpsfc using gfs or gfs_hd, every other hour it seems like it is
> > plotting 3 hour precip, then 6 hour precip, and back to 3 hour, then 6
> > hour precip all the way through the 65 points. This makes the precip
> > appear to pulsate, every other frame. I have attached two images to
> > illustrate the problem. Does anyone have a work around for this
> > issue? The problem is isolated to just gfs data (both gfs_hd and
> > gfs), but doesn't happen with GFS Ensembles.
> >
> > Versions:
> > Grid Analysis and Display System (GrADS) Version 2.0.a9
> > Fedora-13-x86_64
> >
> > Data source example:
> >
> > sdfopen:
> > http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd20101130/gfs_hd_12z
> >
> > Attached files:
> > precip_US_6.png (appears to show 3 hours of precip)
> > precip_US_7.png (appears to show 6 hours of precip)
> >
> > Here is my attempt to work around the issue for just gfs_hd / gfs,
> > though it doesn't solve the problem:
> > (Note: This is the section of my .gs file related to my work around
> > attempt):
> >
> > *grads code
> >
> > t = 1
> > t0 = 0
> > alt = -1
> > while ( t <= 65 )
> >
> > 'set t 't
> > 'define precip = apcpsfc/25.4'
> > if alt > 0 then
> > 'define product = precip(t='t')'
> > 'define over4= precip(t='t')'
> > endif
> > if alt < 0 then
> > 'define product = (precip(t=t) - precip(t=t0))'
> > 'define over4 = (precip(t=t) - precip(t=t0))'
> > endif
> >
> > *more grads code
> >
> > t = t+1
> > say ' = 't
> > t0 = t0+1
> > say ' = 't0
> > alt = alt * -1
> > endwhile
> >
> > Any help here would be greatly appreciated. Thanks again.
> >
> > Sincerely,
> >
> >
> > Jeff Chabot
> > jsc219 at gmail.com <mailto:jsc219 at gmail.com>
> > http://jeffsweatherservice.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://gradsusr.org/pipermail/gradsusr/attachments/20101202/d2cc2397/attachment-0001.html
------------------------------
Message: 3
Date: Thu, 2 Dec 2010 13:06:07 -0800
From: "Huddleston, John" <Huddleston at cira.colostate.edu>
Subject: Re: [gradsusr] Memory Allocation Error When Using PRINTIM
To: GrADS Users Forum <gradsusr at gradsusr.org>
Message-ID:
<F367071F539DC64FB75E7D7690B8160D010D7A96CE74 at EXVMBX003-2.exch003intermedia.net>
Content-Type: text/plain; charset="us-ascii"
Stephen
I'm going to have to punt and defer this to someone who knows about the colors,
lines, levels, etc.
I see http://iges.org/grads/gadoc/shapefiles.html examples have what appears to
be a one-to-one relationship between ccols, clevs, and more; however, I'm lost
with what you are doing with the lines in the shapefiles.
John
John Huddleston, PhD
Cooperative Institute for Research in the Atmosphere
From: gradsusr-bounces at gradsusr.org [mailto:gradsusr-bounces at gradsusr.org] On
Behalf Of Stephen McMillan
Sent: Thursday, December 02, 2010 11:44 AM
To: GrADS Users Forum
Subject: Re: [gradsusr] Memory Allocation Error When Using PRINTIM
Sorry, John, that I didn't send you the version 9-pertinent script last time.
Attached includes required shape draw commands which, of course, requires fewer
commands than last one. It should work, but I won't be able to test it until
later on this evening.
My Task Manager doesn't have the memory display options that yours does, but
thanks for the update.
Stephen
On Thu, Dec 2, 2010 at 12:29 PM, Huddleston, John
<Huddleston at cira.colostate.edu<mailto:Huddleston at cira.colostate.edu>> wrote:
Stephen,
I added the set clevs and set ccols with no problems.
Send me the set shpopts command you want; it wasn't in the script you sent.
Oh, and, I increased the size of the PNG image with no problems as well.
John
John Huddleston, PhD
Cooperative Institute for Research in the Atmosphere
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 Stephen McMillan
Sent: Thursday, December 02, 2010 10:22 AM
To: GrADS Users Forum
Subject: Re: [gradsusr] Memory Allocation Error When Using PRINTIM
John,
Interesting, but you left out some of the commands required to get the desired
image--commands which may or may not be crucial to my memory errors. In
particular, the 'set clevs...' and 'set ccols...' commands before the initial
"tmp2m" display, as well as the 'set shpopts [color]' prior to the first set of
'draw shp...' polyfill commands (since you're using the latest version, I
believe).
Thanks
Stephen
On Thu, Dec 2, 2010 at 11:55 AM, Huddleston, John
<Huddleston at cira.colostate.edu<mailto:Huddleston at cira.colostate.edu>> wrote:
Stephen
After NOAA finally let me download the shapefiles, I used sdfopen, loaded the
shapefiles, and attached is the result from printim. There was no memory error.
NOW, having said that, the Cygwin build is like the pure Linux builds, and not
like opengrads; so, the opengrads extensions do not work. Here is what I used.
set mproj nps
set mpdset mres
set map 15
set lat 10 85
set lon -200 -20
set mpdraw off
set grads off
set rgb 16 0 0 125
set gxout shaded
d tmp2m
set line 7
draw shp admin98
set line 16
draw recf 6.6 3.7 8.1 4.8
set rgb 17 175 175 255
set line 17
draw shp ln_ca
set line 11
draw shp ln_us
set line 11
*shp_polyf admin98 2342
draw shp ln_ak
set line 1
draw shp ln_ca
set line 1
draw shp ln_us
set line 1
*shp_lines admin98 2342
draw shp ln_ak
printim uscan.map.png x960 y720 white
John Huddleston, PhD
Cooperative Institute for Research in the Atmosphere
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 Stephen McMillan
Sent: Thursday, December 02, 2010 9:10 AM
To: GrADS Users Forum
Subject: Re: [gradsusr] Memory Allocation Error When Using PRINTIM
John,
Thanks for offering to do this. Since I don't have an FTP or HTTP site for
placing the files, I am attaching only a somewhat modified version of my
original script. No control file used or needed.
Before running, I opened the latest GFS operational forecast, for example,
http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd20101202/gfs_hd_06z. Script
uses the "tmp2m" variable to set environment. Near top of script are sources
for the three "boundaries" shapefiles (tar.gz format) used. I put extracted
files in the SupportData folder where the "admin98" shapefile is. In script,
edit the "outfile" variable as needed.
Stephen Mc
On Thu, Dec 2, 2010 at 10:29 AM, Huddleston, John
<Huddleston at cira.colostate.edu<mailto:Huddleston at cira.colostate.edu>> wrote:
Stephen
I build the Cygwin ftp://iges.org/grads/2.0/grads-2.0.a9-i686-pc-cygwin.tar
version of GrADS and would be willing to test your data.
Can you zip it up include CTL ans GS files and put it on a FTP or HTTP site to
download?
John
John Huddleston, PhD
Cooperative Institute for Research in the Atmosphere
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 Stephen McMillan
Sent: Thursday, December 02, 2010 8:22 AM
To: GrADS Users Forum
Subject: Re: [gradsusr] Memory Allocation Error When Using PRINTIM
Arllindo, Jennifer,
Obviously the choice of shapefiles and output image dimensions play a critical
part, not to mention the GrADS version you mentioned. Still using 2.0.a7.oga.3,
by replacing one shapefile for just the Alaska portion, I was able to "printim"
an image without the memory allocation error. In this case, I replaced the
shapefile "ln_ak" with "admin98 2342" for AK. However, if I tried to output a
higher-resolution image (say, x1440 y1080), GrADS simply crashed (I briefly saw
an error about something being corrupted). I can do 960x720 or 1200x900 without
a problem.
I have win32 superpack 2.0.a9.oga.1 on my other machine at home, so I'll try the
original script on that this evening. That could be interesting, since it's
about a 10-years-old Windows XP laptop with much less RAM (500MB?). For now,
I'd rather not attempt the COLA version 2.0.a9, since I ran into problems trying
to install it several weeks ago. Perhaps someone else with a9 would like to
give it a shot.
Thanks for your comments and suggestions!
Stephen
On Wed, Dec 1, 2010 at 8:07 PM, Arlindo da Silva
<dasilva at alum.mit.edu<mailto:dasilva at alum.mit.edu>> wrote:
On Wed, Dec 1, 2010 at 7:59 PM, Jennifer Adams
<jma at cola.iges.org<mailto:jma at cola.iges.org>> wrote:
Hi, Stephen --
The error message you're seeing occurs when the printim code tries to allocate
an array that contains the vertices of a filled polygon. It may be that your
shapefiles have single polygons with so many vertices (e.g. the one that fills
in most of Canada) that your 3.2Gb of RAM is not enough, or maybe an integer
isn't big enough to represent the number of elements in the array, so it passes
malloc some junk and you get an error. To complicate things, you are also using
a deprecated shapefile interface that I didn't write.
See if you can reliably reproduce this error with the latest COLA version of
GrADS. If so, then send me the simplest possible script and the required
shapefiles, and I will try to reproduce the error on my own system that has lots
and lots of available memory.
I agree, the new shapefile interface is the way to go. The latest win32
superpack 2.0.a9.oga.1 has exactly the same shapefile code that Jennifer wrote,
you could try that as well.
Arlindo
--
Arlindo da Silva
dasilva at alum.mit.edu<mailto:dasilva at alum.mit.edu>
_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org<mailto:gradsusr at gradsusr.org>
http://gradsusr.org/mailman/listinfo/gradsusr
***************************************************
The information contained in this e-mail message
is intended only for the use of the recipient(s)
named above and may contain information that is
privileged, confidential, and/or proprietary.
If you are not the intended recipient, you may not
review, copy or distribute this message. If you have
received this communication in error, please notify
the sender immediately by e-mail, and delete the original message.
***************************************************
_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org<mailto:gradsusr at gradsusr.org>
http://gradsusr.org/mailman/listinfo/gradsusr
***************************************************
The information contained in this e-mail message
is intended only for the use of the recipient(s)
named above and may contain information that is
privileged, confidential, and/or proprietary.
If you are not the intended recipient, you may not
review, copy or distribute this message. If you have
received this communication in error, please notify
the sender immediately by e-mail, and delete the original message.
***************************************************
_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org<mailto:gradsusr at gradsusr.org>
http://gradsusr.org/mailman/listinfo/gradsusr
***************************************************
The information contained in this e-mail message
is intended only for the use of the recipient(s)
named above and may contain information that is
privileged, confidential, and/or proprietary.
If you are not the intended recipient, you may not
review, copy or distribute this message. If you have
received this communication in error, please notify
the sender immediately by e-mail, and delete the original message.
***************************************************
_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org<mailto:gradsusr at gradsusr.org>
http://gradsusr.org/mailman/listinfo/gradsusr
***************************************************
The information contained in this e-mail message
is intended only for the use of the recipient(s)
named above and may contain information that is
privileged, confidential, and/or proprietary.
If you are not the intended recipient, you may not
review, copy or distribute this message. If you have
received this communication in error, please notify
the sender immediately by e-mail, and delete the original message.
***************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://gradsusr.org/pipermail/gradsusr/attachments/20101202/541ba1c1/attachment.html
------------------------------
_______________________________________________
gradsusr mailing list
gradsusr at gradsusr.org
http://gradsusr.org/mailman/listinfo/gradsusr
End of gradsusr Digest, Vol 10, Issue 11
****************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: firstplot.gif
Type: image/gif
Size: 18830 bytes
Desc: not available
Url : http://gradsusr.org/pipermail/gradsusr/attachments/20101202/252b879d/attachment-0003.gif
More information about the gradsusr
mailing list