David,
The primary problem, the "oops" message says that the file
RADFIL = /usr1/data/dnovak/radar/060212/OKX/KOKX_20001230_1620
can't be opened. That "Feb12, 2006" path, certainly doesn't
match what you used up above in the gpnexr2 portion:
/usr1/data/dnovak/radar/001230/OKX/$time
Could your path there be incorrect?
Otherwise in your script, use "!" as the comment character within the
GEMPAK program (eg, the sections between: gemprog << "name"
and "name".
That is the cause of messages like:
[IP -7[ #CXSTNS is an unrecognized parameter.
One of your CXSTNS lines has a "@" where it shouldn't:
CXSTNS = 41;-74>@40;-72
should be
CXSTNS = 41;-74>40;-72
That "-72" being interpreted as -72 grid points may cause problems later
(when the file can be found). The lat;lon pairs should work otherwise.
Let me know about that path above....
Steve Chiswell
Unidata User Support
On Wed, 2006-03-29 at 13:36, david.novak@xxxxxxxx wrote:
Hi Steve,
Still no go. I've attached what I'm seeing in terms of the text on the
screen and the resulting image. I've also attached the script I'm using.
I appreciate your effort, but if we can't resolve I understand.
Thanks!
Dave
----- Original Message -----
From: Steve Chiswell <chiz@xxxxxxxxxxxxxxxx>
Date: Wednesday, March 29, 2006 3:13 pm
Subject: Re: 20060323: Radar Level II question
Ok...next pass here. Unpack the tarfile in $GEMEXE.
I tested using:
CXSTNS = 40.6;-75.7>40.5;-71.3
GVCORD = hght
PTYPE = lin
YAXIS = 0/20000
CINT = 4/-4
SCALE = 0
LINE = 3
BORDER = 1
SKIP = 0
TITLE = 1/-2/RHI Base Reflectivity Level II ^
CLEAR = yes
DEVICE = xw
TEXT = .8/1/1/111/hw
PANEL = 0
CLRBAR = 1
CONTUR = 0
FINT = 4/-4
FLINE = 30-7
CTYPE = f
RADFIL = /home/chiz/KOKX_20001230_0959
RADPARM = dz
RADTIM = last
INTERP = y
GEMPAK-NEXR2RHI>r
Creating process: xw for queue 1212417
SITE: KOKX
Filename : ARCHIVE2.
Extension: 384
Julian date: 1001230
time: 95910.621000
Processing for SWEEP # 0
Processing for SWEEP # 1
Processing for SWEEP # 2
Processing for SWEEP # 3
Processing for SWEEP # 4
Processing for SWEEP # 5
Processing for SWEEP # 6
Processing for SWEEP # 7
Processing for SWEEP # 8
Processing for SWEEP # 9
Processing for SWEEP # 10
0 elev 0.483398
1 elev 1.487196
2 elev 2.410167
3 elev 3.384627
4 elev 4.308317
5 elev 6.010090
6 elev 9.887094
7 elev 14.595397
8 elev 19.501642
NEXR2RHI PARAMETERS
Radar file: /home/chiz/KOKX_20001230_0959
Date/time: 001230/0959
Vertical coordinate: hght
Endpoints: 40.6;-75.7>40.5;-71.3 Number
of horizontal points: 920
Number of vertical points: 101
Scaling factor: 10** 0 Max: 40.802841 Min:
-36.001469 Panel: 0
FILLED CONTOURS:
LEVELS: -4.00 0.00 4.00 8.00 12.00 16.00
20.00
COLORS: 30 29 28 27 26 25 24
TYPES: 1 1 1 1 1 1 1
LEVELS: 24.00 28.00 32.00 36.00 40.00
COLORS: 23 22 21 20 19 18
TYPES: 1 1 1 1 1 1
Enter <cr> to accept parameters or type EXIT:
Parameters requested:
CXSTNS,GVCORD,PTYPE,YAXIS,CINT,SCALE,LINE,BORDER,SKIP,
TITLE,CLEAR,DEVICE,TEXT,PANEL,CLRBAR,CONTUR,FINT,FLINE,CTYPE,RADFIL,RADPARM,
RADTIM,INTERP.
GEMPAK-NEXR2RHI>
Steve Chiswell
Unidata User Support
On Tue, 2006-03-28 at 15:16, David Novak wrote:
Hi Steve,
Well, now I can plot the radar in the 2D (Thanks!), but the cross
sections still don't work - giving me garbage text on the screen
and a
blue cross section. The last normal text is
date/time: B @ ? : -as you see this is not right. I can't
read
anything else after this...
Dave
Steve Chiswell wrote:
David,
Attached is a tar file with gpnexr2* and nexr2rhi* executables.
Place in your 5.9.1 $GEMEXE directory and unpack there with:
gunzip -c novak.tar.gz | tar xvf -
You should be able to get rid of all that stuff we tried in /tmp/
last week.
Let me know if this improves the situation ;-)
Steve Chiswell
Unidata User Support
On Tue, 2006-03-28 at 11:11, David Novak wrote:
Hi Steve,
Excellent! Thanks.
Dave
Steve Chiswell wrote:
David,
I have been able to duplicate your problem on one of our older
systems.> >>>I have fixed gpnexr2 and am looking at nexr2rhi now. I'll
send you an update when available.
Steve Chiswell
Unidata User Support
On Fri, 2006-03-24 at 08:01, David Novak wrote:
Hi Steve,
No go. The $GEMTBL variable is pointing to
/usr1/programs/nawips5.9/gempak/tables so that looks good.
Gemenviron is
sourced (I see the very fast performance of the speed patch).
And I see
the path:
/usr1/programs/nawips/os/linux/bin (nawips is linked to
nawips59)> >>>>
If it helps, I also noticed that for more recent data my map
background
has totally changed. I've attached a recent case radar plot
using 5.7
and now with the update to 5.9.
If you want, I can give you a call or you can call me (631-
244-0134) to
troubleshoot.
Thanks,
Dave
Steve Chiswell wrote:
David,
there is a failsafe that if no other location can be found,
it just uses
FTG so that it has something...which is what you are seeing,
but this
shouldn't be happening. I get the correct display over NY here.
The NEXRII template is in $GEMTBL/config/datatype.tbl and the
file template is there which matches what you used, but
it could be that your $GEMTBL is not pointing to the correct
release,> >>>>>or didn't source the Gemenviron for the new version?
The garbage seems like more of a symptom of a prpogram
connecting to
a gplt or device driver from an older version. Make sure you
have> >>>>>shut down your old gplts (either gpend or "cleanup -c").
Check your $PATH variable and make sure the 5.7.2p2
executables aren't
in that path. The Gemenviron will add $NAWIPS/os/linux/bin
to your
path for the 5.9.1 version.
Steve Chiswell
Unidata User Support
On Thu, 2006-03-23 at 14:07, David Novak wrote:
Hi Steve,
It's now plotting, but it is plotting over Denver, when the
radar site
is in New York (see attached). You mentioned the
datatype.tbl entry for NEXRII
Where do I look for this? Anything else that could be checked?
Also, I'm finding when runing my screen text becomes wild
(see second
attachment). Any ideas?
Thanks very much,
Dave
Steve Chiswell wrote:
David,
Yeah...thats a couple of years old now. The first iteration
was based on files received in the IDD where the dcnexr2
decoder would
add the station ID to to the file in the appropriate bytes.
My subsequent development works with the many iterations
of the
data formats, bzip2, older format headers etc. and eliminated
the need to munge the file headers pre build 5.0.
Steve Chiswell
Unidata User Support
On Thu, 2006-03-23 at 11:21, David Novak wrote:
Steve,
I'm runing 5.7.2p2, so I bet that's it. I'll update to
5.9 and let you
know what happens...
Dave
Steve Chiswell wrote:
David,
I was able to display your file, so the format is fine.
Are you using 5.9.1 (comparing apples to apples)?
Are you using my datatype.tbl entry for NEXRII which
specified the file
name is %SITE%_YYYYMMDD_HHNN?
Its OK to use a full file path to the file, but the code
will use the
NEXRII template to get the file alias when the site ID
is not in the
data, so that %SITE% string must match your KOKX part of
the file-
which it should, unless your datatype.tbl doesn't have
the NEXRII
template (if you had an NCEP datatype.tbl file for
example).> >>>>>>>>>
Double check that your path is correct. Is that OKX
correct and not
KOKX?:
/usr1/data/dnovak/radar/001230/OKX/
Try running gpnexr2 from the directory containing the
data and check the
file permissions if all else fails.
Steve Chiswell
Unidata User Support
On Thu, 2006-03-23 at 10:34, David Novak wrote:
Hi Steve,
Yup did the gunzip, and now I used the od command and
see what you see.
HOWEVER, I get the same error message.
An example data file and my script is at:
Do you see anything strange?
Thanks!
Dave
Steve Chiswell wrote:
David,
NCDC has compressed the individual files within the
tarfile> >>>>>>>>>>>(each file has a .Z extension).
You have to use the uncompress command on the file. At
that point, the
first 9 bytes should be "ARCHIVE2.", eg:
%od -c KOKX_20011230_0959 | head -1
0000000 A R C H I V E 2 . 3 8
4 \0 \0 , :
With your file naming as shown below, gpnexr2 will be
able to obtain the
site id from the file name which is required in pre
build 5.0 files
that lacked the station ID or location within the data.
Steve Chiswell
Unidata User SUpport
On Thu, 2006-03-23 at 09:49, David Novak wrote:
Thanks Steve and all,
One other question...I recently downloaded Nexrad
Level II radar data
for a Dec 2000 case from the NCDC HADS website:
http://hurricane.ncdc.noaa.gov/pls/plhas/has.dsselect
The data in 2000 is apparently in a different format
than more recent
data, since a more on the data files shows different
text at the top.
Consequently, I get the following error upon trying
to plot using gpnexr2:
Enter <cr> to accept parameters or type EXIT: : No
such file or directory
wsr88d_to_radar: No valid site ID info found.
[IM -3] Image file
/usr1/data/dnovak/radar/001230/OKX/KOKX_20001230_0959
not a supported format
[IM -8] Could not open LUT file ...
[GEMPLT -15] NIPROJ - Invalid projection specified.
[GG -7] No map drawn.
[GEMPLT -15] NIPROJ - Invalid projection specified.
[GG -13] Error drawing lat/lon grid.
Has anyone else noticed this? Is there a workaround?
Thanks,
Dave
P.S. The data file was too large to post...
Steve Chiswell wrote:
David,
We decode the NLDN data from binary files into
GEMPAK surface
files and use SFMAP to plot the data, points, etc.
Since your data is not of the same format as our IDD
feed to
use our dcnldn decoder, you can put your data into the
ascii format used by SFLIST for importing into a GEMPAK
surface file using SFEDIT as shown here:
http://www.unidata.ucar.edu/cgi-
bin/getfile?file=/content/support/help/MailArchives/gempak/msg04454.html>
Steve Chiswell
Unidata User Support
On Wed, 2006-03-22 at 13:58, David Novak wrote:
All -
Is there a GEMPAK program to plot lightning data?
It's not obvious to
me. I have text files with that contain
(1) date, (2) time, (3) latitude, (4) longitude,
(5) peak current and
polarity, (6) chi square value
Thanks!
Dave
