Report to the UNIDATA Users Committee

 

Compiled by Steve Koch

September 30, 1999

 

 

 

 

Part I: Current GEMPAK/GARP Application Capabilities

 

 

 

Part II: Suggestions for Requirements for Future Development

 

Part I: Current GEMPAK/GARP Application Capabilities

 

N-AWIPS Functionality

 

N-AWIPS Components

 

GEMPAK Applications Programs

 

GD Capabilities

 

OA Capabilities

 

SF Capabilities

 

SN Capabilities

 

GEMPAK Software Architecture

GEMPAK Graphics Software (GEMPLT)


GEMPAK Device Drivers

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

GARP Capabilities (beyond those of GEMPAK)

Part II: Requirements for Future Development

 

Suggestions for Future Upgrades to GARP/GEMPAK, or "What I love about AWIPS and NCARGraphics that I wish were in GARP/GEMPAK"

  1. 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.
  2. 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.
  3. 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.

  4. 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 over this.

  5. 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.
  6. 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.
  7. 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 a mile.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. While GOES data can be displayed in GARP, there is no POES data display.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. Remove the 72-character field specification limit in GEMPAK. Word has it that this has been accomplished in GEMPAK 6.0.
  21. 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

  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. There’s no way to display derived quantities and variables on surface plots.
  6. Product Maker in v. 4.2 is a nightmare:
  1. It is extremely difficult to call up old model runs without using SetTime, which is quite cumbersome and annoying.
  2. There is no data listing or editing functions like those in GEMPAK.
  3. 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.
  4. Some satellite data limitations: