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

20010427: GEMPAK 5.6.C.1 Available



Gregg,

I currently send out the Unidata GEMPAK release with 400,000 maximum grid
points. This can get close to 4km for the CONUS (depending on projection).
The 4km stage2 precip grid that is in use by the weather service is
1160x880 (1020800 points)- but that domain is a little larger than
I use.

I can create regional 1km sectors of the country and then display them
as a high resolution conus image. 

At this point I am creating a grid, which is used by any GEMPAK program
(and NMAP/NMAP2). NMAP and NMAP2 use gdplot2, so the no problem there.
I treat the files just as the RCM grids in HAXA00 KWBC.

I have an example in NMAP2 at:
http://www.unidata.ucar.edu/staff/chiz/gifs/nmapexample.gif
This shows combining the radar grid with satellite data, watch
boxes (from dcwtch) and radar anotations from redbook graphics 90R
I convert to VG files.

At this point, I'm primarily concerned about the display of 1 million point
grids. I have created GINI format images from the radar composites.
We already deal with 5000x5000 GINI VIS 1km images. On the one hand, display of
the GINI products is much faster. On the other hand, using the data as
gridded data allows me to create the precip type product with the
RUC data grid in calculations as well as the objective selection
of radar sites shown on the gdradr.html page. Moreover, I can
overlay gridded radar data onto satellite images. And, I can reproject the grid
data.

I'm working of some filter functions to squash some of the ground clutter
at night as well. Lots of possibilities with gridded data that images
don't allow.

Steve Chiswell
Unidata User Support


On Wed, 2 May 2001, Gregory Grosshans wrote:

> Steve,
> 
> Did you decide not to generate a .9km CONUS mosaic because the number of 
> grids would be
> very large (i.e. perhaps over 1 million) and the processing time would be 
> increased as
> well?   Did you integrate this enhancement so the Unidata version of 
> NMAP/NMAP2 displays
> this data?
> 
> Thanks for the detailed answers.
> Gregg
> 
> 
> Steve Chiswell wrote:
> 
> > Greg,
> >
> > The key issues about how long it takes to create a masaic are:
> > 1) The number of gridded data points (I currently use 360,000
> >    for both CONUS and regional)
> > 2) The number of radar sites in the station table.
> >
> > It takes about 10 minutes to run through the projection of all 153 radars
> > into the 360,000 point grid domain the first pass. Then, it takes
> > about 1 minute from then on for all the products thereafter since I save
> > the bounds for each radar in an array. You can also speed up a regional
> > mosaic be knowing ahead of time what nexrad stations will be in the domain
> > and using a smaller station table with just those IDs. You can create
> > this information from the output of the program since it will tell you
> > what radars are being used. I don't do this for my regional mosaic though 
> > since
> > I want it to be a floater- moving with the interesting weather. However,
> > sites that always want a region around them can take advantage of this.
> > I created the RADFRQ parameter so that the user can set up the
> > wait time between each iteration of the program, so that
> > the program doesn't have to exit and lose the projection information
> > that it worked so hard to create.
> >
> > Since it only takes a minute to produce the grid, keeping up
> > with the radar data which is on the order of 5 to 6 minutes
> > is no problem.
> >
> > The gdradr.html page is running on a 4 cpu SUN E450 which is
> > handling lots of data relay, data decoding, DODS servers, LAS servers
> > and other non UNIDATA stuff. I have no problem running the same
> > scripts here on out pentium running X86.
> >
> > The plotting with gdplot2 is a little slow, so I've added a
> > fill option here with just filling in the grid boxes (which are small),
> > rather than using the filled contours. But, primarily, it
> > just takes a while to run through 360,000 grid points.
> >
> > Steve Chiswell
> > Unidata User Support
> >
> > On Wed, 2 May 2001, Gregory Grosshans wrote:
> >
> > > Steve,
> > >
> > > Scott Jacobs indicated you provided the GDRADR program to CDB.  I also 
> > > have looked at
> > > the various web pages you create containing the mosaic data.  I'm curious 
> > > as to how
> > > long it takes to process the .9km mosaic over a portion of the country?   
> > > Did you ever
> > > time it for the whole CONUS?  What type of machine are you running this 
> > > on?
> > >
> > > Thanks,
> > > Gregg
> > >
> > > Steve Chiswell wrote:
> > >
> > > > GEMPAK users,
> > > >
> > > > I have made the Unidata distribution of GEMPAK 5.6.C.1 available
> > > > for download in source and binary formats.
> > > >
> > > > New programs included are:
> > > >    gdradr: creates gridded composites from NEXRAD products.
> > > >
> > > >    gptraj: plots trajectories from gridded data sets.
> > > >
> > > >    dcsvrl: decodes SLS watch bulletins (see pqact.conf example).
> > > >
> > > > New features:
> > > >    dcuair: decodes dropsonde and ship soundings, stores maxwind
> > > >            and tropopause groups, stores raw text portions (see 
> > > > pqact.conf example).
> > > >
> > > >    extended zoom: CURSOR GAREAX
> > > >
> > > >    latlon: new labeling options
> > > >
> > > >    file aliasing extended in additional grid programs
> > > >
> > > >    Added ~250 additional stations to sfmetar_sa.tbl
> > > >
> > > > -----------------------------------------------------------------------------------
> > > >
> > > > For information on New features, see:
> > > > http://www.unidata.ucar.edu/packages/gempak/GEMPAK5.6/whats_new.html#5.6C
> > > >
> > > > Also, the 2001 package training workshop dates have been announced.
> > > > For more information see the online registration page:
> > > > http://www.unidata.ucar.edu/workshops/Training2001/enroll_wkshop01.html
> > > >
> > > > Steve Chiswell
> > > > Unidata User Support
> > >
> > >
> 
>