[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20060323: Radar Level II question

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: Re: 20060323: Radar Level II question
  • Date: Wed, 29 Mar 2006 17:32:39 -0500
Doh! Yup, it was the path in that section. All is good now. Thanks so very much! 
Dave

Steve Chiswell wrote:


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, address@hidden 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 <address@hidden>
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