Value error from PET computation

[Yunlei-Wu]

How to craft a useful, minimal bug report

Describe the bug The PET (Thornthwaite) function gave value error when latitude coordinate of a dataset contains -90 and +90 degree.

To Reproduce Steps to reproduce the behavior:

1. enter: process_climate_indices --index pet --periodicity monthly --netcdf_temp /mnt/d/Files/Thesis/Data/comb_data/Tas_comb_unit_24/ACCESS-ESM1-5_r1i1p1f1.nc --var_name_temp tas --output_file_base /mnt/d/Files/Thesis/Data/SPEI/SPEI_T/PET/ACCESS-ESM1-5_r1i1p1f1 --multiprocessing all_but_one

2. The error occures Expected behavior PET computation can be finished

Screenshots

Desktop (please complete the following information):

• OS: \Window 10 Ubuntu
• Version: \18.04LTS

Additional context I tried to trace the error following the traceback, and I didn't find a condition statement in main.py related to this error. Then I did change the max latitude value and min latitude values in eto.py. Unfortunately, it didn't work. Here is the link to download the dataset: https://drive.google.com/file/d/1y-O00b3hPLRGhawxLThBdMRtfZuq_fX4/view?usp=sharing

[monocongo]

Hi @Yunlei-Wu

Apparently the error message here is incorrect, in that latitude values must be between -90 and 90 degrees north "exclusive" (not "inclusive", as currently worded), i.e. less than 90 and greater than -90.

In this case, the latitude value is -90, and this is what is causing the error, as this is outside of the supported latitude range. The check happens here.

I'm not sure how to handle cases like this, maybe the best thing to do is to skip grid cells that fail this latitude check rather than raise a critical error?

[Yunlei-Wu]

Thanks for your quick reply. @monocongo The problem was solved when I set the lat degree<=90 and lat degree >=-90. In my view, it should be set like this, because the GCMs have the variate latitude range and step size. This time I calculated PET for 22 GCMs, and two of them gave me the error.

[monocongo]

When I first wrote this code there was a limitation that precluded the use of latitude values at the ends of the range (-90 and 90) but this may not be a consideration now since (I think) we're now using different packages for the PET math. I haven't looked into that aspect of this in quite a while, so I can't comment much further.

Are you saying that you've had reasonable results using lat degree<=90 and lat degree >=-90, except for the two GCMs that gave an error? I am happy to make this change if the results look reasonable at -90 and 90, please advise.

[Yunlei-Wu]

Hello @monocongo I checked the plot of datasets today, and the results look reasonable. In my case, I have 24 GCMs, and only two GCMs have the lat 90 and -90 degree boundary, which caused the value errors before. In my view, the 90 and -90 lats are in the border of the global map, and thus it wouldn't have a significant impact on overall results. Therefore, it is not harmful to change the condition of this value warming, especially for the researchers who are using multiple GCMs.

[Yunlei-Wu]

Hello @monocongo While I was re-running the script to calculate the PET of all datasets, an OSError: [WinError 1450] occurred. This error didn't stop calculation, but I have worries that it could cause inaccurate results. This error didn't tell me what the exact problem is, but it could be related to Insufficient system resources according to a question in StackOverflow

The screenshot of the error as follows:

[monocongo]

Thanks @Yunlei-Wu

This appears to be an issue related to Python on Windows.

Windows support for this package is pretty limited these days since I am using Linux exclusively on my home and work laptops. I know it's not a very helpful answer for this, but my recommendation is to use Linux if at all possible to save yourself some headaches.

FYI several users have also reported issues related to NCO on Windows (this package uses NCO to reorder dimensions of NetCDF input files), and I know that the NCO and pynco projects are also Linux focused, so Windows related bugs are not always easily detected when those packages are developed.

[tristanballard]

FWIW I ran into a similar issue with GCMs bounded at -90 and 90. I worked around it by setting input latitude values of -90 to -89.9 and of 90 to 89.9. It will minimally affect the PET calculation, and realistically we never are that interested in interpreting drought indices at the farthest extent of the poles.

[monocongo]

Thanks, @tristanballard, this is a reasonable workaround.

If I remember correctly the Thornthwaite PET implemented here is essentially useless above 60 degrees latitude?