Hello! I am running the Habitat Quality model at 4m resolution and I got an error stating one of my aligned tifs has a ‘row blocksize which can make this function run very slow, create a square blocksize using ”warp raster” or ‘align and resize raster stack’ which creates square blocksizes by default.’ Looking at other posts in this forum with similar issues, I understand this error is likely due to analyzing a large area at high resolution - when I previously ran this model at 30m resolution it worked just fine.
What is a recommendation to address this issue? I am working on a study that is attempting to use a subset of InVEST models to bundle ecosystem services at the city scale, so equivalent resolution analysis would be important across each model. Is it adequate to run this model at the 30m scale and resample to 4m? Are there any published papers that have worked with this type of issue that I could look into, or does anyone have any additional suggestions? Thanks!
Have you checked to make sure that the rasters actually do have a square cell size (like exactly 4m x 4m)? It could be that the model will run successfully if they do.
I see that the error happened after 21 hours, which must be frustrating. If you’re evaluating a large area at that resolution, it will take a long time. But if the rasters do not currently have a square cell size, and you resample and try again, I’d be curious to know if/how that affects the run time.
The raster does appear to have a square cell size (screenshot attached). Do you have any additional ideas on how to approach this? Thanks for your quick response.
Interesting. Is the cell size the same(4x4) for the file intermediate/bareopenland_aligned.tif (which is the specific file that the error message references)? I just want to make sure that the model isn’t altering it somehow.
You could certainly run it at lower resolution, but then you may lose some detail. I’m not sure what all you’re modeling, or what the threat distances etc are, but it’s very possible that you won’t get much extra information from 4m instead of 30m, just a lot of additional pixels with very fine differences in quality. I do understand though that it would be better to be able to run at full resolution so be consistent with your other modeling.
It looks like the file intermediate/bareopenland_aligned.tif also has the 4x4m cell size, so I am not clear if that is the issue (screenshot below). I’m happy to provide the input files I use to run the model if you think that would be useful - it seems as though this is the second to last aligned raster in the intermediate file and of my threat rasters for the data input? I wonder if there is something incorrect with this particular threat/raster I have entered in the model.
@MayaDutta I’m not sure what else to suggest right now, other than sending me your inputs and I’ll check it out. You can post a link to your data here, or email me directly at swolny@stanford.edu.
Looking at your data, and yes it’s probably the case that the combination of 4m resolution, and threat distances up to 12km is causing the error (although the specific error you got is on a threat whose distance is 3km) . I did a quick test using the same 4m input rasters, but dividing all of the threat distances by 100, and it ran through fine.
I’m not sure what else to say about this issue, so will punt to our software team for advice - @jdouglass or @dcdenu4 ?
@swolny@MayaDutta this is a very strange error that I would not expect to see at this point in the model, so I suspect something went wrong during the alignment step.
@MayaDutta could you share the logfile from this run so I can take a closer look?
Hi @jdouglass, thanks for your response. I’m attaching the logfile to this post and can forward you the input data I shared with Stacie as well. I appreciate your help!
@MayaDutta I’m sorry about the hassle here! It turns out that we had fixed this issue in InVEST 3.11.0 (and the fix is still present in InVEST 3.12.0), so if you upgrade to either of those versions the model’s execution should be able to continue without issue. I think you’ll also find that the model will run a bit faster as well with this change.
As it turns out, the error message is misleading and has to do with the linear kernel file used rather than the signal raster, which is absolutely a bug in our underlying geoprocessing library and will be fixed in a future version of InVEST.
