[BUG] SHARPpy resolving different SREF results between versions

[denezrg]

Me and a few members of a discord were discussing tomorrow's tornado potential, and a user of 1.3.0 got the first sounding, while I (on 1.4.0b1) got the second one for the same model, run, hour, location. One thing to note is that I recently upgraded then downgraded to 1.4 then back to the beta.

[wblumberg]

@denezrg - Hmmm. Well, that's not supposed to happen. Thank you so much for letting us know.

Would you be willing to do some more tests for us between these two versions? That might help us work more quickly to a solution. I suspect this might be an indexing problem. Sometimes the source files have hourly profiles and sometimes they don't. Here are some possible tests:

Does this inconsistency also happen with other models (NAM, GFS, RAP, HRRR)? Can you recreate this behavior with the SREF at other times? Can you take a look at the source files (they're in text format) between these two data sources (v1.4.0 uses these both and there may be something not playing nicely between the two)? You might be able to even load the text files into SHARPpy to view the soundings.

• https://mtarchive.geol.iastate.edu/2020/03/12/bufkit/
• http://www.meteo.psu.edu/bufkit/CONUS_SREF_09.html (each data link is in this format http://www.meteo.psu.edu/bufkit/data/SREF/09/sref_kekq.buf)

[denezrg]

I'm in school right now, will probably try that out after tonight's event has concluded. And to answer one of your questions, yes, at least one other location is affected by this issue

[Firefighter14141]

Hey there everyone, I was the other person experiencing this issue with the SREF Soundings last week. I have been laid up with the flu for the last week but will look through everything above and see if I can recreate it.