Introduction

The wgrib2 utility can handle many grib tasks without programming. For more complicated tasks, wgrib2 now has IF-ELSE-ENDIF blocks. However, for some tasks, you need to drive wgrib2 from another program. Calling the wgrib2 utility has been done, but it requires many CPU cycles (call shell, initialize shell, call wgrib2, free resources), and all communications have to be done through files or pipes. Reading and writing of grib files can be done but the performance is suboptimal.

One day, a user sent me revisions to make wgrib2 a C subroutine. He was able to call the new wgrib2 subroutine from a C program to read and write grib files. This development lead to a fortran API for reading and writing grib files. This fortran API is higher level interface than direct calls to wgrib2 and makes reading and writing grib easy. Performance was good if the introduced memory files were used.

Another day, another user sent me code for a python interface to wgrib2. This interface also builds on the wgrib2 subroutine. Since the users/developers have varied needs, there will different levels of the python interface.

1. pywgrib2_s .. s is for simple
   • simple, minimal requirements
   • Requirements: python3.5+, numpy, and wgrib2 shared library
   • read, write grib, based on an extension of the ftn wgrib2api
   • Inventory file is optional for reading but can speed up processing
   • Simple python code, guts in 1-3 weeks by person with minimal Python experience.
   • Most of the development time was spent on learning python, polishing and documentation.
   • See pywgrib2_s main page
   • pywgrib2_s is in beta testing.
2. pywgrib2_lite .. lite version
   • Requirements: python3.6+, numpy, and wgrib2 shared library
   • more conventional python experience
   • alpha testing started, request info to be tester
3. pywgrib2_xr .. for xarray
   • Requirements: python3.7+, Cython, xrray, dask.array, wirlitzer, numypy, wgrib2 shared library
   • read grib, write to be developed later
   • read using xarray
   • more features like interpolation
   • testing started 12/2020
   • source: https://github.com/yt87
   • documentation: https://yt87.github.io/pywgrib2_xy
   • conda packages from anaconda: https://anaconda.org/yt87/repo
   • built/tested on azure for linux-64 and osx-64
4. Common Features of various versions of pywgrib2_*
   • Based on wgrib2 v3.0.0+ library.
   • OpenMP for faster processing of large grids

Expected Reliability

Software has errors because the code in the routines have a problem or because how the routines are called have problems. Problems can be simple coding errors to invalid assumptions. Testing is important, and writting test code is both error prone and often covers too few cases.

The pywgrib2_s is expected to have higher reliability than expected by its age and utility because,

• The wgrib2 library is used by the wgrib2 utility which is widely used and operational at NCEP.
• Wgrib2 is open source which encourages users to find and debug errors.
• Only a handful of routines in the wgrib2 library are called by pywgrib2_s.
• Only a few routines in the wgrib2 library are called by pywgrib2_s but not by the wgrib2 utility. Thereby reducing the number of codes that are infrequently used. Even the infrequently used codes are called by the fortran wgrib2api.
• Only a handful of routines in the wgrib2 library are directly called by pywgrib2_s reducing the errors in "calling the routines".
• Much of the testing can be done by running the wgrib2 utility reducing errors in coding testing programs.
• pywgrib2_s.py started small (5-13-2020: 292 lines including 51 blank lines, and 63 lines of comments)
• pywgrib2_s.py is still small (9-16-2020: 668 lines including 92 blank lines, and 100 lines of comments)

See also: