wblumberg
commented
5 years ago Hi @tennessean !
Thank you very much for catching this. Admittedly, there are some errors that do make it through our review process of the code. I've fixed the function using your code change suggestion. I believe this issue arose as there are some functions we have added to SHARPpy that while rooted in the literature are not present in the code we ported from SPC. Because of this issue, validation of those functions (such as SWEAT) is much more difficult for us to perform with the same rigor we have when reviewing the SPC ported code. Strict comparisons between code bases are just more difficult (and sometimes impossible as an alternative, controlled code base doesn't exist) to perform with these functions. I've added some information in params.py in Commit 13975991780ff1dfd88e9aa84060175cd9e40acc that identifies which functions are not ported from SPC code, which I believe should help users be better alert to these nuances within the SHARPpy code base. Thanks again for bringing this to our attention! I appreciate your careful review of SHARPpy!
@wblumberg
Recently, while checking the calculations on some of the indices currently programmed into SHARPpy, I noticed something odd with the SWEAT Index's calculations as currently implemented. The current implementation was giving out different values from the actual calculation (using a graphing calculator to check the work). I traced the source of the problem to the shear term (specifically line 2943):
As it turns out there's only one closing parenthesis immediately after the np.radians term, with two closing parentheses after the 0.2 term. As a result, the sine term counts the 0.2 term as being added on to the radians term and includes that in its calculations.
The actual SWEAT Index formula has the 0.2 term be outside the sine term instead of inside, as such:
Note the pair of closing parentheses after the np.radians term and the single closing parenthesis after the 0.2 term.
Admittedly, this error is a rather easy one to make, and a hard one to spot--which is why it's always a good idea to double- and even triple-check your work (as I did).
In fact, it would be a good idea to go through the other parameters and recheck their calculations on the off-chance that some other typo(s) could've been accidentally introduced somewhere in the currently-implemented calculations.