The latest version of SHARPpy (running from an Anaconda python window) produced an error.
The tabular text from that sounding which I believe is used by SHARPpy is here http://www.spc.noaa.gov/exper/soundings/18022712_OBS/TUS.txt and has the height out of order (926 mb higher than 925 mb). I don't know if this is because TUS surface pressure is very close to the 925 mandatory level, or whether it is just some error in this sounding. However, somehow, the SPC webpage skewt was still able to plot.
Perhaps there could be similar logic to what the SPC decoder is using to handle these odd situations?
This isn't really a sig problem, more of just a question. From the 12Z TUS sounding this morning, the SPC NSHARP type skewt on the web this morning plotted okay. http://www.spc.noaa.gov/exper/soundings/18022712_OBS/TUS.gif
The latest version of SHARPpy (running from an Anaconda python window) produced an error.
![sharppytuserr](https://user-images.githubusercontent.com/12057398/36755124-73b3e4c6-1bc8-11e8-9152-36308b7963f2.jpg)
The tabular text from that sounding which I believe is used by SHARPpy is here http://www.spc.noaa.gov/exper/soundings/18022712_OBS/TUS.txt and has the height out of order (926 mb higher than 925 mb). I don't know if this is because TUS surface pressure is very close to the 925 mandatory level, or whether it is just some error in this sounding. However, somehow, the SPC webpage skewt was still able to plot.
Perhaps there could be similar logic to what the SPC decoder is using to handle these odd situations?
Thanks.
George