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

Re: 20060227: gpnexr2



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