[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20010925: 20010924: Gempak Omega plotting problem
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.
- Subject: 20010925: 20010924: Gempak Omega plotting problem
- Date: Tue, 25 Sep 2001 18:20:51 -0600
Hi Mike. I have to work from home for the time being....so the 56K dialup is really a pinch when trying to load your annimation applet. Anyhow, let me know how the images are tomorrow. I can always launch the browser and go sift the deluge of resumes were getting for job openings. Thanks for resending your original question. I lost sight of it in my work box with all the status reports, committee meeting, hiring panel, and other operating system holy war messages I have pending at the moment. Steve >From: Mike Voss <address@hidden> >Organization: UCAR/Unidata >Keywords: 200109251754.f8PHs3120565 >Steve, > >The irony kills me, there has been data to fill the plots every day since I do > n't know when, and of course the day you look at it nothing is there....arrrg > h! > >I will try to set the SCALE and see if that fixes the problem. If not I'll sen > d an email in the AM (when I know the plots are there) so you can check out w > hat we're talking about. Much thanks, >Mike > >At 06:09 AM 9/25/2001 -0600, you wrote: > >>Mike, >> >>I couldn't see much in the urls. Most frames do not have any color fill. >>The CONUS had none. >> >>One thing I notice is that you are specifying all your FINT & FLINE >>values. But, you are using a SCALE=999. >> >>When scale is 9999, it allows GEMPAK to choose the appropriate scaling based > on the >>values in the data. What you might be seeing is the scale value changing betw > een frames. >> >>If you are doing a loop and expecting certain FINT values, then you should se > t SCALE appropriately >>so that you have the same value throughout you loops. >> >>Steve Chiswell >>Unidata User Support >> >> >> >>>From: Mike Voss <address@hidden> >>>Organization: UCAR/Unidata >>>Keywords: 200109242314.f8ONED117319 >> >>>Hello, >>>I sent this message last Monday (9/17), but maybe it got lost in the shuffle > o >>> r never made it. Anyway, we're still having the same problem so I'll try ag > ai >>> in. Thanks for any help you can provide!! >>> >>>-------- >>>Hi Steve, >>>We add an omega grid to the MRF201 data daily with the gdomeg program. We d > is >>> play this grid in a polar hemispheric output: >>>http://www.met.sjsu.edu/weather/models/mrfp/omeg700-ani.html >>>and a USA (CONUS) output: >>>http://www.met.sjsu.edu/weather/models/conusmrf/omeg700-ani.html >>> >>>The only differences in the .nts files which create these images are with GA > RE >>> A and PROJ parameters (see below). The polar output plots fine. The CONUS > ou >>> tput files, however, have a strange color scheme that develops. This does n > ot >>> happen consistently as you can see by looking at today's output, but does > te >>> nd to occur in the later forecast periods, i.e., days 7 through 10. In comp > ar >>> ing the same forecast hour image in >>>the two different outputs we have found that the max, min, and zero values >>>are in the same place geographically in both images. The difference is >>>that the CONUS output (when having trouble) seems to use all available color > s >>> to contour from zero to the max or min value. In doing this the incremental > s >>> pacing is too small and therefore shows false values when compared to the c > ol >>> orbar. Do you have some insight into what may be causing our problem? Bel > ow >>> I have a sample .nts file from each script and a copy of the script itself > u >>> sed to generate the images: >>> >>>.nts from the polar plot: >>>GDFILE $METDAT/grids/2001010900_mrf201.gem > >>> >>>GDATTIM first > >>> >>>GLEVEL 700 > >>> >>>GVCORD PRES > >>> >>>PANEL 0 > >>> >>>SKIP 0/3;3 > >>> >>>SCALE 999 > >>> >>>GDPFUN mul(-1,omeg)!quo(hght,10) !kntv(wnd) > >>> >>>TYPE f!c !b > >>> >>>CONTUR 0 > >>> >>>CINT 3 > >>> >>>LINE 1/1/1 > >>> >>>FINT -6;-5;-4;-3;-2;-1;0;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19 > >>> >>>FLINE 21;22;23;24;25;26;27;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20 > >>> >>>HILO > >>> >>>HLSYM 2;.5//21;1//hw > >>> >>>CLRBAR 1/v/ll/.01;.25/.6;.03 > >>> >>>WIND bk1/.4 > >>> >>>REFVEC > >>> >>>TITLE 1/-3/@ Omega(-ub/s) & Hght(dm)!1/-2/ Valid ~ > >>> >>>TEXT 1 > >>> >>>CLEAR y > >>> >>>GAREA 10;-90;10;-90 > >>> >>>PROJ str/90;-90;0 > >>> >>>MAP 32 > >>> >>>LATLON 32/1/1/30/30;90 > >>> >>>------------------------------------ >>> >>>And .nts for the conus plot: >>>GDFILE $METDAT/grids/2001010900_mrf201.gem > >>> >>>GDATTIM first > >>> >>>GLEVEL 700 > >>> >>>GVCORD PRES > >>> >>>PANEL 0 > >>> >>>SKIP 0/3;3 > >>> >>>SCALE 999 > >>> >>>GDPFUN mul(-1,omeg)!quo(hght,10) !kntv(wnd) > >>> >>>TYPE f!c !b > >>> >>>CONTUR 0 > >>> >>>CINT 3 > >>> >>>LINE 1/1/2 > >>> >>>FINT -6;-5;-4;-3;-2;-1;0;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19 > >>> >>>FLINE 21;22;23;24;25;26;27;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20 > >>> >>>HILO > >>> >>>HLSYM 2;.5//21;1//hw > >>> >>>CLRBAR 1/v/ll/.01;.25/.6;.03 > >>> >>>WIND bk1/.4 > >>> >>>REFVEC > >>> >>>TITLE 1/-3/@ Omega(-ub/s) & Hght(dm)!1/-2/ Valid ~ > >>> >>>TEXT 1 > >>> >>>CLEAR y > >>> >>>GAREA 10;-140;55;-55 > >>> >>>PROJ lcc//6;2;2;1 > >>> >>>MAP 32 > >>> >>>LATLON 32/1/1/30/30;90 > >>> >>>--------------------------------------------------- >>> >>>And the script (this is identical for both plots except for the directory in > fo >>> ): >>> >>>#!/bin/csh -f >>>#This script uses GEMPAK to make gif files of virt. velocity and wind @700mb > s. >>> >>> setenv DISPLAY rossby:1 >>> source /usr/local/gempak/gempak5.6/Gemenviron >>> set CURRENT_MRF=`ls -t $METDAT/grids/*_mrf201.gem | head -1` >>> cd /export/home/baggett/gempak/mrfp >>> >>>#if (-e omeg700f00.gif ) then >>> rm -f omeg700*.gif* >>>#endif >>> >>>rm gemglb.nts >>>set a=00 b=06 c=12 d=18 e=24 f=30 g=36 h=42 i=48 j=54 k=60 >>>set l=72 m=84 n=96 o=108 p=120 q=132 r=144 s=156 t=168 u=180 >>>set v=192 w=204 x=216 y=228 z=240 >>>foreach time($a $e $i $l $n $p $r $t $v $x $z) >>>#set a=00 b=06 >>>#foreach time($a $b) >>>set thing = f$time >>>echo $thing >>> gdplot2<< EOF >>> restore omeg700.nts >>> gdfile=$CURRENT_MRF >>> gdattim=$thing >>> device=gf|omeg700$thing.gif|800;540 >>> clear=y >>> text=1/2/1/hw >>> title=1/-3/@ Omega(-ub/s) & Hght(dm)!1/-2/ Valid ~ >>> r >>> >>> e >>> >>>EOF >>> >>>rm gemglb.nts >>> >>>gpend >>> >>>end >>>------------------------------------------------- >>> >>>thanks for your help!! >>> >>>Mike >>> >>> >>> >>>-------------------------- >>>Mike Voss >>>Department of Meteorology >>>San Jose State University >>>One Washington Square >>>San Jose, CA 95192-0104 >>> >>>408.924.5204 voice >>>408.924.5191 fax >>> >> >>**************************************************************************** >>Unidata User Support UCAR Unidata Program >>(303)497-8644 P.O. Box 3000 >>address@hidden Boulder, CO 80307 >>---------------------------------------------------------------------------- >>Unidata WWW Service http://www.unidata.ucar.edu/ >>**************************************************************************** > < > >-------------------------- >Mike Voss >Department of Meteorology >San Jose State University >One Washington Square >San Jose, CA 95192-0104 > >408.924.5204 voice >408.924.5191 fax >
- Prev by Date: 20010924: Gempak Omega plotting problem
- Next by Date: 20010925: ship and buoy decoding
- Previous by thread: 20010924: Gempak Omega plotting problem
- Next by thread: 20010925: ship and buoy decoding
- Index(es):