FAQ#

Why another sounding library, and why is SHARPpy not being maintained anymore?#

First, a little history…

SHARPpy was initially conceived and developed by Dr. Patrick Marsh – at the time, a Techniques Development Meteorologist for SPC, currently the Science Support Branch Chief – with a few specific goals in mind:

  • Provide the community with an open-source version of the computations used in operations and research at SPC

  • Provide the community with the same visualization platform (NSHARP) in use at SPC for forecast operations

  • Remove the dependence on GEMPAK/N-AWIPS, which made portability quite challenging

For more information, check out the original blog post or the original 2012 American Meteorological Society talk.

However, by 2014, the development of SHARPpy had stalled for a multitude of reasons. I (Kelton Halbert) found the code sitting in Patrick’s GitHub repository during my sophomore year, and through a combination of boredom with the meteorology program, a love of programming and storm chasing, and a stubborn fixation on having the same tools SPC uses, I set out to complete it. I was later joined by Dr. Greg Blumberg and Dr. Tim Supinie, who provided major and significant contributions to get it over the finish line. Once completed and released to the wider world, it was published in the Bulletin of the American Meteorological Society.

By all accounts, the SHARPpy effort was incredibly successful and quite literally saw world-wide adoption. However, over the last decade, a few issues became apparent:

  • Pure Python, and even Python + NumPy, was not particularly performant when working with gridded data sources.

    • This meant SHARPpy would never be a viable replacement for SPC mesoanalysis and model post-processing code.

  • While file IO, numerical methods, and graphical visualization were appropriately separate within the library, maintaining all aspects as part of a single, large project became cumbersome.

  • Creating a truly cross-platform GUI in Python was incredibly cumbersome at best, and outright broken at worst.

    • Getting the Qt bindings to work on all platforms was not always trivial.

    • There were persistent issues with text and window scaling on various displays and platforms.

    • All rendering was done by the CPU, making it slow for high-resolution and ensemble data.

  • Packaging of native binaries that did not require for a user to install Python worked at first, but became increasingly difficult with time.

  • I wrote a lot of code during my “Programming Structures and Abstractions” class, in which I learned Object Oriented Programming, and suddenly everything was a nail that needed to be hit with an object hammer.

    • Too much logic became obfuscated by class methods, hidden control flow, and trying to be ‘smart’ about how and when to compute things… this ended up drastically reducing the understandability of the code and reducing the freedom of the programmer to build something with the tools offered by the library.

SHARPlib seeks to address these deficiencies within a more narrow, focused scope…

  • This library is only for the computational routines, making it a foundation to build other packages and projects on.

  • Written in C++ for performance, bindings generated by Nanobind for low-overhead/high-performance Python bindings.

  • Provides a more composable API

    • No more ‘profile’ object that obscures control flow and details on how something is computed. Instead, arrays and function arguments are passed explicitly. No memory or state is managed by the library.

    • All routines that involve moist ascent can explicitly choose how parcel ascent is computed (adiabatic, pseudo-adiabatic, liquid-only, liquid+ice)

    • This means SHARPlib provides not only the tools to compute various parameters, but provides a toolbox of generalized algorithms to build new methods, too.

  • Binaries are natively compiled and packaged for each platform, while also being compatible to build from-source on most NOAA systems with minimal dependencies.

Why doesn’t SHARPlib use double precision (64-bit floats) in its computations?#

The short answer is that, in most cases, it’s not necessary.

The longer answer is that 32-bit math is faster, plenty accurate for our use cases, and results in a lower memory footprint. SHARPlib is intended for both real-time operational workflows and research datasets, and 32-bit floats provide the accuracy and performance needed to fulfill both needs.

If a time comes in the future where double precision becomes necessary, we can revisit this and use template generics to facilitate both precision types.

Why doesn’t SHARPlib use the exact solution for X/Y/Z?#

We aren’t opposed to implementing exact solvers to computations. The simple answer is that the starting point for a lot of SHARPlib calculations are in well-established and cited approximations with well understood and bounded errors. These approximations also typically tend to be faster than exact solutions. In the process of writing SHARPlib, some thermodynamic routines were updated incrementally to use more accurate formulations and solvers, while others remain rooted in the Bolton 1980 era of computations. If there is a particular exact solution desired for SHARPlib, open up an issue or pull request and we will investigate its implementation and performance implications.

How does this library compare with MetPy, or other meteorological libraries?#

Other libraries like MetPy, SounderPy, etc are excellent resources, and SHARPlib is not intended to be a replacement for anything other than SHARPpy. MetPy has excellent community support, NumPy integration, and often has more accurate/exact implementations of certain moisture and thermodynamic computations. SHARPlib was intended to unify internal tooling and processes at SPC, but be provided back to the meteorological community as as public resource. It has a different focus on performance and needs internal to SPC.

What is the policy on accepting contributions to SHARPlib?#

Contributions are absolutely welcome to SHARPlib! A few notes to consider, however…

  • Maintainers do occasionally work operational forecast shifts, have high-priority operational and research resposibilities, and may not be available for review or merging for weeks or months at a time.

  • This library is first and foremost focused on the needs of SPC. If your PR or issue isn’t addressed or merged, or if it isn’t within the scope of this library, it is not an indictment of your contribution. While