Possibility of valid range check for latitude/longitude arguments to certain functions?
Closed this issue · 3 comments
Recently I had to debug a notebook that was causing the python kernel to crash without providing any error message. I tracked it down to a "-999" missing value flag being (incorrectly) passed to the longitude field of gsw.SA_from_SP. It would be convenient for users if the SA_from_SP function wrapper (and other similar functions) may report when an invalid input is received instead of attempting to proceed with its calculation.
The description of the SA_from_SP function does clearly state that the valid range of longitude is from -360 to 360, and the function is well behaved in that range. When outside this longitude range, the function still attempts to calculate a value, and the value it does return is erroneous but is not flagged as such. I experimented with a range of longitudes and found that sometimes it gives a nan, sometimes it gives a value that seems "reasonable" but is still wrong (e.g., the value at lon=361 deg does not equal the value at lon=1 deg), and sometimes the function crashes the Python kernel.
This behavior should be reproducible with the following code snippet, which causes my Python kernel to crash:
import gsw as gsw
gsw.SA_from_SP(35,10,-999,0)
I think the place to fix this is going to be in the gsw_saar() function in gsw_saar.c, both here and in GSW-C. That's where the longitude is being normalized to the 0-360 range and then used to calculate an index. However, I can't reproduce either of your failure modes in a quick trial on my Mac, with 3.6.19-py310hde789be_0 from conda-forge.
Please provide details about your platform, gsw version, and mode of installation.
Also, please provide the exact code and output you get for this case: "sometimes it gives a value that seems "reasonable" but is still wrong (e.g., the value at lon=361 deg does not equal the value at lon=1 deg),"
Thanks for the response. I checked my kernel and realized I tested this with an old python gsw install (a few years old, predating this key change). I tried my routines again with an updated gsw package and find the solutions are well behaved (and identical) for any multiple of 360.
I will close this issue. The documentation could potentially remove the "-360 to 360 degrees" qualifier, as this no longer appears to be necessary.