Report to the UNIDATA Users Committee
Compiled by Steve Koch
September 30, 1999
Part I: Current GEMPAK/GARP Application
- N-AWIPS Functionality
- N-AWIPS Components
- GEMPAK Applications Programs
- GD, OA, SF, SN Capabilities
- GEMPAK Software Architecture
- GEMPAK Graphics Software
- GEMPAK Device Drivers
- GEMPAK and GARP Supported Platforms
- GARP Capabilities
Part II: Suggestions for Requirements
for Future Development
- Suggestions for Future Upgrades to GARP/GEMPAK
- AWIPS 4.2 Limitations
Part I: Current GEMPAK/GARP Application Capabilities
- Data ingestion
- Data analysis
- Data display
- Data integration
- GEMPAK (text-based interface and Unix scripting)
- Applications programs
- Graphics routines
- Device drivers
- MOTIF-based Graphical User Interface (GUI)
Displays and animates surface, upper-air, sounding, numerical model, satellite,
and radar data
Displays and animates satellite and radar imagery
Displays and animates pre-generated numerical model metafiles in GEMPAK
Displays textual data from FOS and NOAAPort data feeds
Interactive Skew-T and hodograph interface for upper-air, numerical model,
and ACARS data
GEMPAK Applications Programs
- Gridded data programs (GD)
- Graphics utilities programs (GP)
- Objective analysis programs (OA)
- Surface data processing programs (SF)
- Sounding data processing programs (SN)
- Contour plotting (lines and color-fill)
- Vertical cross sections (in pressure, height, isentropic,
- Time sections
- Vertical profiles
- Vector plots
- Numerous diagnostic functions (vector and scalar)
- Standard meteorological quantities
- Mathematical basis operators
- Barnes OA to transform irregularly spaced data to a regular grid
- Flexibility to control degree of smoothness and grid
- First-guess field option (e.g., from a model)
- Station model plots
- Ability to plot both standard and derived quantities
- Meteograms for standard and derived meteorological
- Data listing and editing functions
- Flexibility in station model plotting (color, size,
placement, units, density)
- Ability to plot buoy, ship, mesonet, ACARS, lightning
- Upper-air map plots in pressure, height, and isentropic coordinates
- Vertical profiles, Skew-T, and Stuve plots
- Station cross sections
- Time-height sections
- Wind profiler data
- Flexibility in station model plotting (color, placement,
units, size, density)
GEMPAK Software Architecture
- Data of all kinds are stored in GEMPAK format. Data may be operational
or research, real-time or retrospective, and may be converted from formats:
- McIDAS AREA file (satellite or radar)
- GRIB (models)
- DDS/ASOS/METARS (raw surface data)
- NOAAPort GINI (satellite)
- NIDS Level III and WSI NOWrad (radar)
- BUFR (hourly profiler data)
- NetCDF (6-minute profiler data)
- Others (SHEF, NWS bulletins, lightning, MOS reports,
- Data and grids are editable (using text editor or
- GEMPAK software is modular, using an extensive set
of Fortran subroutines grouped by function into the GEMPAK library GEMLIB.
Each subroutine name begins with a two letter code indicating the library
function followed by an underscore (e.g., SN_OPNF).
- Scalar or vector diagnostic grid may be computed and
added to the grid file.
- Complicated diagnostic functions are built using nested
grid operators on either basis math functions or higher-level meteorological
- Numerous (> 10) map projections have been developed.
- Units and scaling factors are known for all variables
- All equations and program callable GEMPAK library
subroutines are documented in a Users Guide, Programmers Guide, and/or in
the form of online help. This provides the user community with:
- Equations and open source code for examination
- Ability to easily write new routines (contrib)
GEMPAK Graphics Software (GEMPLT)
- Internally handles transformations from one coordinate to another
- Coordinate transformations and utility functions are
performed in GPLT
- A device driver that draws lines, text, and symbols
is a second subprocess. This subprocess can remain active after an application
- Plotting characteristics defined in one program
may be used in other programs that follow it in the same session
- Graphics overlays are produced in this manner
- Mouse button can be used to select an area, point,
or cross section end points. Only the area can be input by this method in
- GEMPAK/GARP uses color numbers to specify graphics
colors, rather than the color wheel/spectrum method used in AWIPS. The number
of colors is fixed 32 for graphics, 128 for satellite imagery, 20 for
radar imagery, though this may be configured (e.g., to 64 for satellite imagery)
GEMPAK Device Drivers
- X Windows (XW)
- NTRANS and standard vanilla CGM metafiles (NC, VC)
- PostScript (landscape, portrait, color or gray levels)
- GIF (GF)
- HP plotter format (HP)
Important limitation: NC, VC, PS, and HP
only allow vector-based printing. Adding image bitmap capability is necessary
to permit printing of imagery (radar, satellite). Of course, XW and GF provide
both vector and bitmap printing.
GEMPAK and GARP Supported Platforms
- Solaris 2.X
- SGI IRIX 6.x
- HPUX 11.0
- IBM AIX 4.3
- Solaris X86 for Intel 2.x
- Linux (gcc/f2c) Kernel 2.2.10
- DEC OSF/1 4.0
GARP Capabilities (beyond those of GEMPAK)
- GARP is a GUI wrapper for many of the capabilities of GEMPAK
- Hypertext help menu
- UNIDATA release of GARP is Y2K compliant. Promised
v. 6.0 of GEMPAK ("NMAP") will also be compliant.
- GUI selection of predefined color LUTS, image fading,
animation controls, and "depictables" (size, packing, etc.)
- Time matching of analysis against a model forecast
- Continuous data readouts can be obtained from the
cursor (position, pixel value, and distance away from a selected point)
- Auto-update feature adds the most current data to
the graphics frame
- Ability to remove single frames from a frame loop
- Ability to save frames (current or a loop) in GIF
- Macros can be run to create complex displays:
- Field Description Files (FDF) are comprised of a
list of key value pairs for building GEMPAK variables and passing information
to the GUI.
- A macro allows one to combine a number of FDFs together
to create a single graphic (or overlay).
- Macro is selected by the user from a pull-down menu.
- Users can modify macro parameters interactively
by input on a command line before the display routine is invoked.
- Some functions in GEMPAK scripts cannot be performed
in GARP macros (e.g., manipulations requiring multiple files from multiple
- Since GARP utilizes the underlying GEMPAK functionality
for much of its capabilities, maintaining the basic library functionality
is important. On the other hand, NSHARP does not use GEMLIB upper air libraries
for much of its thermodynamic calculations, so maintaining separate functionality
Part II: Requirements for
Suggestions for Future Upgrades to GARP/GEMPAK, or
"What I love about AWIPS and NCARGraphics that I wish were in GARP/GEMPAK"
- First and foremost: a robust PostScript device driver for GARP,
which currently only allows GIF output (or X Window dumps) that can be converted
to PostScript for printing outside of GARP. Recall that the PostScript device
driver in GEMPAK 5.4 does not support bitmap printing.
- Just as important: when are we going to see annotation
capabilities that have been promised to the user community with the release
of NMAP? Having the ability to draw and add text onto GEMPAK images and saving
them as PostScript would go a long way to giving the research community handy
tools for producing publication-quality graphics without the need to export
the graphics to such packages as Adobe Photoshop.
- AWIPS uses a multi-panel display consisting
of a main window and four sub-windows for storage of graphics. This design
was necessitated by the need to "localize" AWIPS to the WFO, and
to have larger scales of display centered on that location ("WFO",
"state", "regional"). While this has obvious operational
advantages, it could also have just as much advantage in educational and research
usage of GARP. One can launch multiple GARP sessions, but that is more cumbersome
and difficult to manage.
- AWIPS excels at color rendering in color-filling
contours and also at making it easy for the user to alter the colors. Changes
needed to GEMPAK:
- Ability to change RGB values in a LUT and save
them interactively using a continuous color spectrum instead of discrete
values (32, 128)
- Ability to change line and text attributes quickly
and easily. AWIPS design should serve as the model for how to do this.
- Line colors change unpredictably every time a
new graphic is loaded in GARP (not in AWIPS). The user must have control
- GEMPAK and GARP have problems showing features
in the lower levels near complex terrain on cross sections because of
the crude horizontal interpolation procedure used. Oftentimes, there are no
isentropes displayed below the level of the maximum terrain. This really should
be fixed. NCARGraphics and AWIPS do not suffer from this easily remedied problem.
- Text manipulation should be divorced from the graphics
display (as in AWIPS). When fonts are changed, they affect the drawing
of other graphical attributes in GARP and GEMPAK. For example, overlays of
contours and vectors on a cross section may result in different ordinate scales.
- When you zoom in on a graphic, GARP will go back to
the data file and extract more data (if available) to redraw the graphic.
This can take quite awhile. An improved ability to refresh overlay
fields and to unload graphics is needed. AWIPS outshines GARP here by
- Ability like GEMPAK has to define the end points of
a cross section by drawing a line on a map with the mouse, or selecting a
point to bring up a sounding. Furthermore, these mouse inputs should
be integrated between the map, cross section, and sounding programs as they
are in AWIPS.
- AWIPS has a cursor readout function using the
mouse. One can instantly read discrete values of location and pixel values
(such as SAO data, satellite brightness temperature and radar reflectivity).
While GARP has this ability in most ways, it does not have an SAO data readout.
- GARP and GEMPAK cannot display special observations.
This is a feature of the dchrly decoder, which bins observations into
1 hourly and up to 3 undecoded secondary observations.
- NSHARP should be fully integrated within GARP,
just as endpoint specification in AWIPS is integrated into the sounding display.
This would allow the user to call up a sounding by picking a point on a map,
manipulate the sounding using rubber-band methods, and instantly see the results.
- Ability to do a layer average over multiple levels,
not just two as done presently in GEMPAK and GARP. This is particularly helpful
for calculating layer-mean winds and other layer quantities.
- There should be a more user-friendly way to compare
model forecasts in GARP and GEMPAK than the present way of using special
symbols (+ ^ @) to specify the model forecasts.
- The current method for obtaining isentropic map displays
and cross sections is based on vertical interpolation from pressure coordinates
at individual points. Fully three-dimensional isentropic objective analysis
schemes have been around for 20 years, but have not found their way into
GEMPAK. These give much more consistent results.
- While GOES data can be displayed in GARP, there is
no POES data display.
- The inability to combine multiple satellite and radar
images, and also overlaid with topographic backgrounds, is in part the result
of the way that GEMPAK draws its graphics and in part a function of the use
of different map projections. This does not appear to be a problem in AWIPS.
Perhaps a similar approach should be instituted into GEMPAK/GARP graphics.
- An ability to write out to GEMPAK parameter values
that are specified in an FDF (GARP macro). It is often much quicker and convenient
to alter values in GARP and see instant results than it is to use GEMPAK interactively.
- More diagnostic functions (e.g., the full Miller frontogenesis
function) should be added to GEMPAK. It seems as though development of diagnostic
capabilities has come to a near-halt in GEMPAK lately. The user community
should be a more direct partner in this development, since NCEP does not seem
to have the interest or resources to put into this effort.
- There should be a broader choice of NetCDF converters
for GEMPAK (not just for converting wind profiler data). This would make it
much easier to transfer data between AWIPS and GEMPAK. Word has it that this
has been addressed to some degree in GEMPAK 6.0.
- Remove the 72-character field specification limit
in GEMPAK. Word has it that this has been accomplished in GEMPAK 6.0.
- VAD (Velocity-Azimuth Display wind profiles) should
be an option added to the NIDS display features in GARP, since these products
are already contained in the NIDS data sets.
AWIPS 4.2 Limitations
- The source code is not available like that of GEMPAK. This imposes a
very strong limit on the ability of the user community to add functionality.
- AWIPS is not an open architecture. HP computers with
24-bit accelerated graphics cards are required for AWIPS. The cost of the
required machines is still prohibitive. COMET is acquiring new HP machines
at a cost of $12K each; most universities won't spend that kind of money (though
they could acquire previous generation HPs that might work OK).
- It is a major pain to bring retrospective data for
analysis into AWIPS, in part because it uses "localizations". Kevin
Schrab from NWS Western Region has developed a means to ingest NetCDF satellite
data, mesonet data, and NOGAPS model data into AWIPS through the LDAD. He
uses a McIDAS-X server, data ingest from NESDIS and elsewhere, and converts
the AREA files to NetCDF format in AWIPS.
- GEMPAK allows easy incorporation of research data
into surface and upper-air files. This is a strength of GEMPAK, but a major
weakness of AWIPS.
- Theres no way to display derived quantities
and variables on surface plots.
- Product Maker in v. 4.2 is a nightmare:
- Nearly impossible to create products that are not
already on Volume Browser (e.g., Petterssen frontogenesis function, multiple
- No basic meteorological parameters (equivalent potential
- Reverse Polish construct translates into a virtual
inability to nest higher level grid functions to create complex diagnostic
- Vectors and arrows cannot be displayed
- It is extremely difficult to call up old model runs without using SetTime,
which is quite cumbersome and annoying.
- There is no data listing or editing functions like
those in GEMPAK.
- Cross section end points should be able to be selected
using the mouse rubber band click-and-drag methods. The cross section program
also does not allow the user to select the bottom and top levels for display.
- Some satellite data limitations:
- POES data is limited (SSM/I, AMSU products), though
this beats GARP
- It is cumbersome to select specific images in a loop
- Image overlay is limited to 8 bits. Furthermore, satellite
only gets 4 bits if another image (radar, topography, etc.) is overlain, despite
the fact that AWIPS requires 24-bit accelerated graphics cards.