I am having problems with the seasonal Water Model. The model runs fine and produces almost every output file, but B and B_sum are missing. At the end it throws the “overflow encountered” error.
I checked in this forum for an answer and this is pretty similar, if not the same issue
However, even though I developed all changes suggested in the comments and answers to that particular question, I was not able to avoid this error. I extracted every raster by the mask of the DEM but it did not have impact in eliminating this error.
Great that you tried the suggestions in the other thread, thanks for letting us know. There are two other things I’d check, related to that previous thread about the DEM. When you extract the other rasters, I would extract them with a buffer around the DEM, not with the DEM itself. Some input layers (often climate) are usually coarser in resolution than the DEM, and when you clip them by the DEM itself, there can still be missing areas around the edge.
The other thing I wonder is if NoData cells in the other rasters that are within the DEM boundary could cause the problem. For example, soil data often has NoData values where there are water bodies. I would check the other rasters for NoData values within the area, not just around the edges, fill them in if they exist, and see if that helps.
Otherwise, I’m punting to the software team again.
@swolny despite all the efforts to do the modifications you suggested to the data, I still get the “overflow encountered error” . I have tried it many times with no possitive result. I upload my data and maybe you can help me put here, to understand what’s no functioning properly.
I also upload the log file of the latest runInVEST-Seasonal-Water-Yield-log-2019-11-05–10_40_56.txt (57.2 KB)
thanks!
Hi @felipebenra, the issue you mention looks very similar to another issue I believe we’ve recently fixed. Could you try this development build and see if it works for you? Let us know if it doesn’t and we can debug further.
Hi @jdouglass, thanks for sharing the development build.
I tried it but unfortunately it didn’t work, same issue-> “overflow encountered”.
However, I repeated the same exercise (although not in the development build, only version 3.7), for a smaller area and it worked.
One difference between the run of the larger (8889 col and 6695 rows, 30 m DEM as a reference) vesus the smaller area (3311 col and 2956 rows, 30 m DEM) is that in the first one I used a multipart polygon in comparisson to a singlepart polyogon in the second case.
I don’t think this is an issue in this case but I am just listing the differences between de model runs in orther to clarify this further for other users.
Hope you can help me!
Felipe
The issue resolved by the dev build I sent you had to do with a mismatch between valid DEM pixels and having nodata values in some other layers where the DEM is valid. The dev build fixes this issue in one place we found it, but if you’re still encountering a similar error, perhaps there’s a related issue somewhere else in the model?
Could you send us your input data via google drive, dropbox, etc so we can take a closer look at this? It’ll be easier to debug this way.
So, the issue here is that one of your precipitation rasters (pp_buffer/maule_mes12.tif) has nodata pixels over some parts of the DEM. Since the nodata value is -3.40282e+38, we quickly overflow the float64 variable when going to sum the values of the output pixels and an overflow error is raised.
The short-term workaround for this is to make sure that all of your precipitation rasters (in this case, maule_mes12.tif) have valid pixel values over all DEM pixels.
In the longer term, I’m going to talk with the model lead about the best way to handle this within the model itself so that we can just fix the issue at the root.
Thanks for taking time to have an in depth look at my files, I really appreciate it.
I will correct the precipitation tiff (incredible that I missed those pixels) and also check out the development build.
I will let you and the community know, how it went.
