Hi! Not sure if you got the link to Google Drive I sent you a couple of days ago… I sent it to your stanford email…
Thank you @Lara! I did indeed receive your inputs in my inputs. I’m so sorry about the delay on this … I’m currently traveling, but I’m hoping to have some time to take a look at this today.
Hi @Lara,
Thanks for sharing your inputs!
So, the issue here is that each threat raster does not completely overlap your LULC. The Habitat Quality model expects that ALL threat rasters cover the entire study area, not just the areas where there are threat values of 1.
Given that this should just be an issue with raster extents, this issue should be resolved if you can make sure that all of your threat rasters cover your entire LULC raster.
Let us know how this goes!
James
Hello, so I was able to work out the extent issue and finally ran the model. It took 91 hours to run, I don’t know if that’s normal. There is an evident error in the habitat quality output raster, since its only showing 0 and 1 values, nothing in between. The log is too big to upload it here so I sent it to your email, along with the output raster.
Thanks again!
91 hours sounds like a very long time! Thanks for sending your quality_c.tif and logfile.
Based on the logfile, almost all of the runtime is being spent in the convolutions (which model distance-based decay from threat pixels, among other things). The distance of the convolution (MAX_DIST, in km in the threat table) is converted to a maximum radius in pixels and then this radius distance is used to compute the convolution’s kernel. The ways to speed up the computation for convolutions are to either:
- Reduce the
MAX_DISTvalue or - Run the Habitat Quality model with larger pixels
Regarding quality_c.tif, the values are indeed pretty close to 0 or 1, but I’m seeing some variation between 0.999999 and 1:
