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.
- 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.
- pywgrib2_lite .. lite version
- Requirements: python3.6+, numpy, and wgrib2 shared library
- more conventional python experience
- alpha testing started, request info to be tester
- pywgrib2_xr .. for xarray
- Common Features of various versions of pywgrib2_*
- Based on wgrib2 v3.0.0+ library.
- OpenMP for faster processing of large grids
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)