NDR: DEM 30m resolution

Hi,

I hope everyone is having a nice holiday and able to take a break!

I am trying to run the NDR model using 30m DEM resolution; however, it seems to crash after running for over 24hrs. I have previously run the model with over 100m resolution and it ran just fine. Is it possible to tell if this is an error due to my processing capacity or an error with the model?

Please find a google folder with all my files including the failed run: InVEST - Google Drive

Thank you!

Sarah

Hi @sarahhalperin,
Could you please also share your runoff proxy and watersheds files in the google folder?

In your log file, there are many errors saying LZWDecode:Corrupted LZW table and TIFFReadEncodedTile() failed. It’s likely that one of your raster files is corrupted.

2 Likes

Thank you so much for the help! I have added the files to the google folder. I would suspect it might be my DEM because I am able to run the analysis with the same inputs, but a different DEM just fine.

How do I fix a corrupted file?

Thanks again! I really appreciate this resource. It has been so helpful and vital!

Hi @sarahhalperin ,

Hmm, this LZWDecode error is a bit unexpected. We had experienced it in InVEST 3.8, but it should have been fixed in InVEST 3.9. We just released InVEST 3.10.0, could you try downloading that (download here) and seeing if the error persists?

The LZWDecode issue is coming from GDAL, which we use to read and write raster and vector datasets, and the fact that it’s happening in an intermediate raster (a mask of pits, part of our hydrological pit filling algorithm) is interesting. One of the many things that we’ve updated in this latest version of InVEST is the underlying GDAL library version, so there’s a good chance that the issue may have been fixed as a consequence.

If that doesn’t fix it, could you be sure to add the rest of the Shapefile component files (wbdhu12_tvproj.dbf, wbdhu12_tvproj.prj, etc. everything with the wbdhu12_tvproj basename) to the Google Drive folder? We need all of the component files in order to be able to try to reproduce the issue.

Thanks!
James

1 Like

Hi @jdouglass ,

I apologize for not adding in those files originally. I have downloaded InVEST 3.10.0 and re-run the analysis, but it still seems to be failing. Do you mind trying to run it on your end to see if you get the same sort of error?

Thank you so much,

Sarah

1 Like

Hi @sarahhalperin,

I’m downloading your data now and will see if I can reproduce / debug the issue. More soon!

Doug

Hi @sarahhalperin,

I wasn’t exactly able to reproduce your problem but did encounter some issues when running your data. We’ll make an issue and do a deeper dive into what might be going on, but in the meantime I found that replacing the nan nodata values for NED_IUDfill.tif allowed me a successful run. I have uploaded a file NED_IUDfill_nodata.tif to the shared drive where the nodata value is now set to -999.0. Can you try using that file and running with your other inputs?

Cheers,

Doug

Hi @dcdenu4,

That seemed to work; however, I get a quite different result. Would a large change in magnitude of N export make sense with a change in DEM resolution? Originally, I had a max N export value of ~41 and now its ~1.5.

Thanks so much for your help!

Sarah

Hi @sarahhalperin -

As noted in the User Guide, the n_export.tif result gives values with units per pixel. So yes, it makes sense that the max N value would change with a change in DEM, since the modeling results are given in the same resolution as the DEM.

~ Stacie

Thanks so much! That is what I thought, but wanted to confirm.

I really appreciate your help!

Sarah