I’m running the NDR and while most pixel values of the surface export raster are as expected (between 0 and 1), a minority of cells in the export output raster are above 1. It’s only a tiny proportion of cells, but they are mostly confined to a couple of counties. I’m not sure what is causing this, and I wondered if anyone might be able to help?
I’ve had a look through the input data, but I can’t figure out what the problem is. The biophysical table has most land cover types as 0, with Arable being 1. Looking at the input DEM, Land Use and Nutrient Runoff Proxy rasters and Watersheds vector, all I can surmise visually is that the high values are where Arable is present, though these are not the only instances of Arable, nor are the patches of Arable only big or small. High values are present both near the watershed boundary and inland.
In the sample I ran, values reach 1.13, and using the whole geographic area they reach over 3.
If anyone has any insight into this, I’d love to hear it! I’ve attached my logfile, and can privately share my sample data.
Thanks for including your logfile! Could you try downloading the latest version of InVEST, 3.14.0, and see if that corrects the issue? Please let us know if it does not and we can go from there.
I’ve just downloaded 3.14.0 and I’m now getting a lot of self-intersection errors I didn’t have in the last version, I’ll be right back once I’ve sorted them out.
Interestingly, when I run the model using sample and full watershed vectors (all other data inputs remain the same), fewer cells in the sample export than full export appear >1, see below.
@jdouglass or anyone else, do you have recommendations of what to try next?
Emily
PS If it’s helpful for anyone, I had to tweak a few self-intersecting watershed boundaries, and add a Land Use category 0/nodata with the upgrade to v3.14.0.
Hi @emilyu, I’m sorry about the delay getting back to you on this. Could you share your complete set of inputs with us so we can take a closer look? I think it’ll be much easier to debug this by looking at the data.
Hi James, yes I’d be happy to - as the data are sensitive, is there a way to do this privately? I have parameters and data saved in a .tgz file, or would a zip file be better?
Sure, no problem, could you share them with my email, jdouglass@stanford.edu so I can take a look? .tgz works great, thanks! If the data are large (more than a few megabytes), using a file sharing service like google drive might be easiest.
HI @emilyu, thanks for sharing your inputs, and as a datastack! Makes it very easy to reproduce this behavior. I confirm that I am also seeing values exceeding 1 in the P surface export, but I am heading out of the office for the rest of the week and will pick this back up on Monday. Sorry for the delay!
OK, so the direct answer to your question is that surface export is greater than 1 because the model is actually using the modified load in the calculation of the surface load, which has been scaled by the Runoff Proxy Index, and RPI is >1 in many places because it’s normalized by the mean, not the sum, of the RP pixel values. The User’s Guide section on Nutrient Loads describes this more fully.
In this sense it seems to me that surface export is more of a potential for surface export rather than the actual surface export. @swolny@RafaSchmitt does that seem correct to you?
Thank you for reading into this for me! I’ll wait and hear what those you tagged suggest.
In the meantime, going by what you said, would it make sense for me to cap the >1 values at 1 for realism? I will be multiplying these values by measured application rates, so I can’t really say there is more of a nutrient than possible in a cell.
