Re: 20060227: gpnexr2

Gerry,

I had replied that I did see the behavior you described when
the KFWS radar was using VCP32, and the updated RSL routine fixed that
problem (in addition to a new ORDA issue I mentioned today, seen with
Houston that I assume will eventually make its way to other sites).
Since the VCP pattern varies from time to time, I suspect that your
displays would magically work/not work depending on weather conditions
and the VCP selection by the radar site. The bonus is that the new ORDA
will be handled now- so you wanted that change anyhow ;-) so its a good
time to install the updated version.

I was waiting to hear back to go ahead and repost the distribution for
all platforms and source tar files- which I might have to bump the 
distribution version at that point.

Steve Chiswell
Unidata User Support




On Thu, 2006-03-02 at 16:52, Gerry Creager wrote:
> Steve,
> 
> I got overcome bty events, overall, but I had thought I'd understood 
> that you were going to look at some data and check it out, then tell me 
> if there was additional homework I had to do.
> 
> I'm concerned in that the scripts were "working" and then stopped with 
> no known changes on my part: Did the data service change, as I've been 
> caching the files as the come in, upon receiving the EOF marker.  If 
> something changed in thei encoding or EOF mark, I could be getting bad data.
> 
> I'll get the updates for GEMPAK and the RSL lib and make sure they're 
> incorporated, tonight from the hotel.  Thanks for looking at the HGX 
> problem; I'm hoping this will fix the range folding issue I've been seeing.
> 
> I'll try to advise tomorrow after I test/play tonight.
> 
> gerry
> 
> Steve Chiswell wrote:
> > Gerry,
> > 
> > I didn't hear back from you, but know you were going to be on travel.
> > 
> > I'll just add to this message that the CHANGES log for the RSL library
> > included for 1.34, Feb 16, 2006:
> >  * 1. wsr88d.c: Fixed a bug in checking msg_type.  The problem occurred 
> > while
> >  *    processing data from Houston, which recently switched over to the new
> >  *    Open RDA (ORDA) being implemented by NEXRAD.  Msg_type is in the
> >  *    righthand byte of a two-byte word, the left containing Channel ID,
> >  *    but the full two-byte value was being used to check msg_type.  This
> >  *    became a problem when ORDA used a non-zero value for Channel ID.
> >  * 2. wsr88d.c and wsr88d_to_radar.c: Added information for new VCPs 12 and
> >  *    121.
> > 
> > So, aside from anything else, this change upgrade will be important in
> > that regard. I have verified that the FWS radar is displaying well,
> > which looks good today with the system moving to the north in Oklahoma.
> > 
> > Steve Chiswell
> > Unidata User Support
> > 
> > 
> > 
> > 
> > 
> > On Mon, 2006-02-27 at 13:41, Steve Chiswell wrote:
> > 
> >>Gerry,
> >>
> >>I tested the display with the 23Z files from KFWS for Feb 24 which
> >>did show a problem when being read.
> >>
> >>I believe there is a VCP32 typo in the sampling rate.
> >>I have recompiled the rsl library and relinked
> >>the device drivers as well as gpnexr2, nexr2rhi and nmap2.
> >>I have reposted the Linux binary tar file under:
> >>
> >>http://www.unidata.ucar.edu/downloads/gempak/nawips-5.9.1/binary/
> >>
> >>Make sure that the web pages show Feb 27th for the posting date!
> >>
> >>See if this solves your problem, and if so, I'll recompile all
> >>the distributions and repost them after checking through the various
> >>VCP scenarios.
> >>
> >>Steve Chiswell
> >>Unidata User Support
> >>
> >>
> >>
> >>On Mon, 2006-02-27 at 10:46, Gerry Creager wrote:
> >>
> >>>Steve,
> >>>
> >>>Thanks for the rapid response and good explanation.
> >>>
> >>>Steve Chiswell wrote:
> >>>
> >>>>Gerry,
> >>>>
> >>>>Regarding the Level2, I'm assuming your meant KFWS. Using tilt=list
> >>>>is only showing a single level, which probably means that
> >>>>the RSL library isn't processing something in the file.
> >>>>I'll take a look and see what I can track down in that code and send
> >>>>you an email when I have that information. Unidata has a seminar series 
> >>>>event today which will preemt my availability this afternoon but I
> >>>>should have some information by tomorrow afternoon if all goes well.
> >>>
> >>>Tomorrow should prove more than adequate, especially if I can get some 
> >>>hotel bandwidth to address any suggestions once I'm in Norman.  Thanks 
> >>>for the effort.
> >>>
> >>>
> >>>>As for CONDUIT, the 215 (20km) and 212 (40km) are the same areal 
> >>>>coverage of the domain, so if the 212 isn't sufficient, neither would
> >>>>the 215 (or the 218 12km 3-D pressure grids which we stated was our
> >>>>planned replacement of the 215 surface grids).
> >>>>
> >>>>The 32km grid is what I believe is called the "master sector" which is
> >>>>a different areal coverage than the "awips" 211, 212, 215, 218. At
> >>>>present, the 104 grid (90km) is the grid which gives the larger than
> >>>>awips coverage, which won't meet your 32km needs. The GFS .5 degree
> >>>>similarly wouldn't either. Can you provide the domain requirements
> >>>>your project requires?
> >>>
> >>>Ideally, we'd go from 50W through about 125W in longitude, and 5N to 60N
> >>>in latidude.  We're trying to initialize large enough to cover UNC's 
> >>>ADCIRC domain which covers roughly 5N-60N, 60W-100W, as well as our own 
> >>>MM5 CONUS and sub-CONUS requirements.
> >>>
> >>>
> >>>>We can certainly entertain replacing the 104 with a higher resolution
> >>>>data set, or adding other data sets- but as discussed at the C2 meeting,
> >>>>the current moratorium at NWS makes it impossible to change either the
> >>>>data stream contents of CONDUIT or the hardware (either NWS supplied
> >>>>or Unidata supplied). Given adequate hardware and networking, the LDM
> >>>>should have resources to burn in delivering data, so we are in a 
> >>>>mode of planning what can be done when the NWS finishes the transition 
> >>>>away from their current AFS network. We will address the action items
> >>>>related data stream contents and hardware suitability as possible.
> >>>
> >>>Understood.
> >>>
> >>>
> >>>>I'll pass along your suggestion to Linda Miller regarding CONDUIT as
> >>>>well.
> >>>
> >>>Thanks.  I appreciate your effort and support.
> >>>
> >>>Regards,
> >>>Gerry
> >>>
> >>>
> >>>>On Fri, 2006-02-24 at 14:39, Gerry Creager wrote:
> >>>>
> >>>>
> >>>>>Steve,
> >>>>>
> >>>>>We're looking at the data available on CONDUIT for NAM models.  We 
> >>>>>(SCOOP folks) need a domain that's larger than that represented by the 
> >>>>>awip20 (NCEP 215 grid) but at 32km or finer resolution.  This makes the 
> >>>>>awip40 stuff problemmatical.
> >>>>>
> >>>>>Is there any chance of seeing, or getting, something on the NCEP 221 
> >>>>>grid, which does cover the extents we need?
> >>>>>
> >>>>>On another note: If Unidata does put hardware on the TOC floor to 
> >>>>>facilitate CONDUIT, what are the chances of getting additional data, 
> >>>>>such as AWIP12/AWIP32 added to CONDUIT?  Would it help for me to offer 
> >>>>>to put hardware solely for that purpose on the floor and then offer, as 
> >>>>>EXP, those products, if we were successful?
> >>>>>
> >>>>>Just looking for alternatives.  FTP'ing data from NCEP has been a 
> >>>>>challenge off and on for awhile now.
> >>>>>
> >>>>>Also, I've been looking again at the gpnexr2 stuff.  I can send files, 
> >>>>>or we can look at, say, this morning's data for KFWD where there's stuff 
> >>>>>out there, but all I seem to be seeing is a radial set.
> >>>>>
> >>>>>How'd you like to look at this, or what do I need to continue doing for 
> >>>>>homework?
> >>>>>
> >>>>>Thanks, Gerry