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

> Steve,
> Thanks for all your help with this. I really appreciate finally being
> able to resolve this problem. One last question - is there a way to
> display a color bar (I'm using GPMAP) for the wind speeds? I tried
> IMCBAR and CLRBAR but didn't get anything. . .
> 
> Thanks,
> Greg
> 


Greg,

The legend gets plotted by default (eg no way to turn it off) in the
current distribution. I didn't have the NCEP routine initially when I first 
added
the product, but now that the NCEP dist has all the infrastructure for
QSCT, I use that.

Steve Chiswell
Unidata User SUpport




> Unidata GEMPAK Support wrote:
> > 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