Seasonal water yield model keeps giving ufunc "isfinite" error

InVEST-Seasonal-Water-Yield-log-2020-07-13–16_06_25.txt (60.0 KB)

Hello all,

I’ve been having no success so far in managing a complete error-free run of the seasonal water yield model. The error that keeps occurring is the one which reads “ufunc ‘isfinite’ not supported for the input types, and the inputs could not be safely coerced to any supported types…”.

I see this error has been mentioned a couple of times in the forum, but none of the solutions seem to apply to my case. I have had the problem in both InVEST 3.8.5 and 3.8.6. After multiple tries and careful checking, I cannot find any obvious errors in the input layers like different raster projections or missing values in the csv tables.

If anyone could help pinpoint the source of this error it would be much appreciated.

Hi @lukezw -

Thanks for posting the log file, and checking out previous forum posts about this. It’s not obvious from the log file what’s going wrong, but I do have to wonder if it has something to do with the path to the biophysical table having periods and dashes. The quick thing I’d do is move the biophysical table and climate zone table from where they are now to the folder where your other inputs are (H:/GIS Luke/East Africa/InVEST layers/) and see if that helps. (that path still has spaces, but the model so far has dealt with that, so maybe it’s ok.) If that doesn’t help, you can point me to your inputs and I’ll check it out: swolny at

~ Stacie

Hi Stacie,

Thanks a lot for getting in touch. I’ve tried again with the relocated files (see the log to check if I seem to be correct) but still getting the same error. The log file linked below is more complete this time, I think because I deleted all files in the cache from previous runs, so I don’t know if that will help you at all. I’ve had to share it through my Google Drive, as the file is 56 mb!

What would you need from me to be able to check out the inputs? I wonder if the size of the region might be an issue. We are working on valuation of multiple study regions across East Africa, but to save time are trying to see if we can run one Invest model for the broader East African region, and than extract results for our focal areas from there. However, perhaps this scale is way too large for the model! Currently, the layers used in the model cover Kenya, most of Tanzania, South Sudan, Uganda, Rwanda and Burundi.


Hey Luke -

Oh dear. The first thing I’m seeing is that you’re getting LZW errors before the ufunc error. This is a bigger software problem that is still being worked on by the software team. It seems to happen with particularly large datasets, and so far there’s no workaround that I’m aware of, is that correct @jdouglass?

Another thing could be the naming of your precip rasters. The requirement is this (from the User Guide):
"Folder containing 12 rasters of monthly precipitation for each pixel. Raster file names must end with the month number (e.g. Precip_1.tif for January.) "
It looks like your precip rasters are not named this way, they are more like “prcp_a3_EA_01.tif” and “prcp_a4_EA_01.tif”. Try correcting these file names (your ET0 rasters might need the same adjustment) and see if that changes anything. You might still get the LZW error though.

If that doesn’t help, and I’m going to try to run the model and replicate the problem, I’d need all of your inputs. It is giving the error with the quickflow calculation, so theoretically I could look at the inputs that go into that without needing everything, but that’s still a majority of the data (precip, rainy days, land cover, biophysical table…) and it wouldn’t allow me to actually try running the model.

If you do end up sending the whole data bundle, the easy way to do it is to use the model interface, which will let me just drag and drop it into my SWY window and get all of the parameters exactly like you’re using:

  • File > Save as
  • Datastack type: Data archive
  • Check the box next to “Use relative paths”
  • Post the result to Google Drive or wherever

If you want to do some sleuthing before sending the data… The first thing I’d probably look at are the rainy day and biophysical tables, make sure they are actually comma-separated, don’t have any blank lines at the end, or have any other oddness that can throw off processing CSVs (much of that is only visible when you look at the file in a text editor like Notepad, not Excel.)

Then I’d double-check the precipitation and soil group rasters, do they have valid values (for example, the soil group can only have values 1-4), do they have No Data values set (I think you may have already checked for that?) etc.

Aside from the LZW error, the models can usually handle pretty large datasets, but there’s always a computational limit. What is the resolution of your DEM? That will be the processing resolution of the model.

~ Stacie


The only workaround at the moment is to use a development preview of what will eventually be released as InVEST 3.9, which can be installed from this development build. Seasonal Water Yield is basically unchanged in this development build from what is in InVEST 3.8.x, so you should be just fine to use it here.

For the other error (TypeError: ufunc 'isfinite' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe'') could you check to see that your climate zones raster has a defined nodata value? Not having one defined could cause this error to happen.


1 Like

Hello Stacie and James,

I think those precipitation files you are referring to Stacie are actually made by the model? They are in the cache_dir folder of the workspace directory. The actual precipitation were named alright I think.

We tried running the model on a smaller region today and were having the same ufunc ‘isfinite’ error crop up time and again, but the LZW one did disappear. It was only when I was triple checking the data layers before sharing them with you that I spotted the precipitation layers still didn’t have a defined NoData value, even though I thought I had fixed this. The model finally ran error free once this was fixed, much to my relief.

I will try the larger region using the development build referenced by James, but we are happy to finally have the model running at a smaller spatial scale, even if it means multiple runs for our various study regions.

Thanks both for all the tips.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.