[GEMPAK #LEY-181797]: Problems plotting QuikSCAT winds w GEMPAK

Greg,

each of the 9 regions has data broadcast in chunks, so there are many ISXX05 
products
for example that make up that region of the plot. The gap you see is due to the 
plot/data time.

I have noticed that NESDIS has WMO header times up to 5 hours in the future,
eg, the $GEMDATA/wsct directory files being created by the LDM FILE
action have future dates, which is problematic. You may want to try a pattern
such as:

HRS     ^ISXX(..) KNES ([0-3][0-9])([0-2][0-9])([0-6][0-9])
        FILE    data/gempak/qsct/%Y%m%d%H.bufr

The above will file the products according to product iunsertion time, rather 
than the
patterns grabbed from the WMO bulletin times.

The 5.10.4 distribution has an option in $GEMTBL/config/prefs.tbl
to control the time range window for the QSCT/ASCT/QBUF etc plots.

You may find it convenient to use the NMAP2
gui data->misc->qbuf to plot/loop
the Quikscat data as well rather than using "last" in gpmap..

Steve Chiswell
Unidata User SUpport


> Steve,
> Thanks for the reference - I understand now the coverage of these
> data. One more question though - I ran my same script again this morning
> with a garea=-20;180;60;0. I got the following plot which looks more
> like what I expected but there is a large chunk of data missing south of
> Mexico between 90 and 100 W. I'm wondering why such a large chunk of
> data is missing. Is this fairly typical? Also - Is there a way to plot
> more than the last 4-hours worth of data?
> 
> Thanks - sorry for all the questions,
> Gregs
> 
> 
> Unidata GEMPAK Support wrote:
> > Greg,
> >
> > The region of coverage for each of the ISXX01 through ISXX09
> > is shown in figure 3 in the PDF which you can find here:
> > http://ams.confex.com/ams/pdfpapers/70665.pdf
> >
> > Note that the region of coverage is 130E to 35W.
> > Your map region is too far east. The region of swath coverage for
> > 4 hours should show 3 swaths more or less.
> >
> > Try just setting GAREA = -90;-180;90;180 and PROJ=CED to see the
> > general coverage now that you have verified that you are FILE'ing
> > the data and it is being located on your disk through the datatype.tbl 
> > entry.
> >
> > Steve Chiswell
> > Unidata User Support
> >
> >
> >
> >> Steve,
> >> The QBUF data are being picked up from the HRS feed as shown on your
> >> quikscat example web page. I'm not sure sure how to tell if HRS is
> >> coming from NOAAPORT or not. Would you like me to send you a sample QBUF
> >> file from our server?
> >>
> >> Also - since I'm not specifiying the the QBUF file in the SATFIL
> >> field what assumptions are being made about where the files exist that
> >> it is trying to get?
> >>
> >> Thanks,
> >> Greg
> >>
> >> Unidata GEMPAK Support wrote:
> >>> Greg,
> >>>
> >>> What version and OS are you running. There have
> >>> been some bugs fixed along the way so can never rule
> >>> out checking current distributions.
> >>>
> >>> John's problem however as sent to me (though he never
> >>> actually provided me with his input to GPMAP) was that he was trying to
> >>> set SATFIL as his QBUF file. These are not images however. You
> >>> can overlay on a satellite image, but the qbuf data are not
> >>> what get set in SATFIL. You must store the ISXX bufr messages from 
> >>> NOAAPORT
> >>> and you must have the QBUF data type defined in datatype.tbl to match the
> >>> file'd name/location. The bufr data on NOAAPORT are not the grids from JPL
> >>> displayable as QSCT however so be sure that you are using the NOAAPORT
> >>> data if you are using the QBUF entry.
> >>>
> >>> Other than that, please provide your settings in GPMAP and/or NMAP2.
> >>>
> >>>
> >>>
> >>>> Steve,
> >>>> We are working with John Merrill of URI on a project called PASE -
> >>>> Pacific Atmospheric Sulfur Experiment. I hear he was having exactly the
> >>>> same problems I was having in getting anything more than a blank plot
> >>>> when trying to plot QuikSCAT winds with GPMAP. This is something I had
> >>>> given up on because we were never able to make it work. I'm wondering if
> >>>> you have come across others who have this same problem and whether you
> >>>> have any idea of how to solve the problem? I know it works on Unidata
> >>>> machines but there must be some other piece missing that we don't have
> >>>> and don't know we are missing. . .
> >>>>
> >>>> Greg
> 
> 
> 
> --
> 
> ~~N~A~T~I~O~N~A~L~~C~E~N~T~E~R~~F~O~R~~A~T~M~O~S~.~~R~E~S~E~A~R~C~H
> Greg Stossmeister                      e-mail: address@hidden
> NCAR/EOL                               phone: (303)497-8692
> P.O. Box 3000                          web: http://www.eol.ucar.edu
> Boulder, CO 80307-3000
> ~~~~~~~~E~A~R~T~H~~~O~B~S~E~R~V~I~N~G~~~L~A~B~O~R~A~T~O~R~Y~~~~~~~~
> 
> 


Ticket Details
===================
Ticket ID: LEY-181797
Department: Support GEMPAK
Priority: Normal
Status: Closed