wblumberg
commented
8 years ago Okay, so my testing change has created a fix for the LFC calculations, and it potentially has the benefit of speeding up the parcelx() routine, but the code is still not identifying an EL. The code enters the "EL Possibility" logic though.
This bug is part of what seems to be a several year attempt to force SHARPpy to calculate the EL and LFC correctly...
While running SHARPpy on a multi-year radiosonde dataset (+5 years), I've randomly encountered an new/potentially recurring issue where the EL/LFC calculations don't play nicely with certain radiosonde profiles (I've encountered this only with 2 radiosondes for standard and significant level data, but I haven't checked extensively for whether this is a problem for the high-resolution data). At the end of the parcel lifts in parcelx() for some parcel types, the EL variables are reported as a masked value and the "lfcpres" parcel value is negative. Upon visual inspection of the profile and the parcel trace, there is an obvious LFC and EL. After some debugging, it seems the code appropriately finds the correct LFC, but upon iterating further, the code identifies a second LFC, which oddly enough is the EL. but begins performing logic related to the "LFC Possibility" section for it instead. It enters the while loop, which doesn't break until the 5 mb increment eventually forces a negative value for "lfcpres" and "lfchght".
I have some ideas for how to fix this, but I wanted to document this for others.