While running SHARPpy on a large radiosonde dataset, I encountered a couple of troublesome soundings that for one reason or another would have missing equilibrium levels and negative LFC pressures values and height values. Upon visual inspection of the data, it was apparent that this was a bug as the parcel trace had a definable LFC and EL. After looking at parcelx(), I found some faulty logic within the LFC and EL codes. As this is relevant to the core numerics of the program, I've documented the changes below for review.
The below changes have been made to parcelx():
1.) Out of the two criteria for identifying the LFC (see the if-else statement within the LFC Possibility code, lines 1844-1867), while loop within the "else" block now has a limitation that in order to iterate further, the variable pe3 that is decremented by 5 mb in the while loop must remain positive.
2.) The code block that sets many of the parcel indices now has a requirement that "pe3" must still be positive. A consequence of this is that I've removed many calls to interp.py from the while loop, which should facilitate more speed. These changes make the Possible LFC code look more similar to the Possible EL code block.
2.) Instead of setting the EL to a masked value each time we identify possible LFC (a positively buoyant layer over a negatively buoyant layer, e.g. the first if statement for the Possible LFC code block), I have modified it to only set the EL and MPL parcel values to be masked if and only if we have identified a new LFC first.
I've tested this code using some of my radiosonde data, and I have found that these changes both eliminate the problem and do not cause any correct calculations of LFC/EL from previous radiosondes to become incorrect.
While running SHARPpy on a large radiosonde dataset, I encountered a couple of troublesome soundings that for one reason or another would have missing equilibrium levels and negative LFC pressures values and height values. Upon visual inspection of the data, it was apparent that this was a bug as the parcel trace had a definable LFC and EL. After looking at parcelx(), I found some faulty logic within the LFC and EL codes. As this is relevant to the core numerics of the program, I've documented the changes below for review.
The below changes have been made to parcelx(): 1.) Out of the two criteria for identifying the LFC (see the if-else statement within the LFC Possibility code, lines 1844-1867), while loop within the "else" block now has a limitation that in order to iterate further, the variable pe3 that is decremented by 5 mb in the while loop must remain positive. 2.) The code block that sets many of the parcel indices now has a requirement that "pe3" must still be positive. A consequence of this is that I've removed many calls to interp.py from the while loop, which should facilitate more speed. These changes make the Possible LFC code look more similar to the Possible EL code block. 2.) Instead of setting the EL to a masked value each time we identify possible LFC (a positively buoyant layer over a negatively buoyant layer, e.g. the first if statement for the Possible LFC code block), I have modified it to only set the EL and MPL parcel values to be masked if and only if we have identified a new LFC first.
I've tested this code using some of my radiosonde data, and I have found that these changes both eliminate the problem and do not cause any correct calculations of LFC/EL from previous radiosondes to become incorrect.