Habitat Quality: An error occured while writing a dirty block

Hello! I’ve been running the HQ model and this error appears thousands of times: An error occured while writing a dirty block. I’m attaching the log. I have no idea what this error means or how I can fix it.
Thank you so much in advance for your help.

Hi @Lara, could you attach the logfile from your model run so we can take a look? It will help a lot with debugging.

Thanks,
Jame

Apparently I can’t upload the file, I don’t know why, I have tried several times and it’s not working… How can I deliver the log to you?

Curious! If you could email it to me (jdouglass@stanford.edu, and please be sure to include a link to this post for reference), I’ll be able to take a look.

James

@Lara, thanks for sending your logfile! So, based on the logfile, there are a couple things I’d suggest:

The first thing I notice is:

08/26/2019 18:18:53  root               INFO     Running InVEST version "3.3.3"

InVEST 3.3.3 is pretty old and it’s quite likely that we’ve fixed a variety of issues with the model (possibly even including this one). If possible, I’d strongly suggest upgrading to the latest development version (download here).

There’s another line, though, that I think is related to the raster creation error messages:

08/26/2019 18:18:58  natcap.invest.habitat_quality DEBUG    Max distance in pixels: 17500000.000000

That’s a lot of pixels! So many, in fact, that it looks like it’s overflowed the integer counter that GDAL is using internally. Could you make sure that the threat rasters are all projected in meters and that they all have the same projection as the lulc raster? I’ve seen similarly large pixel distances appear when the threat rasters are unprojected.

Let us know how this goes!
James

Ach, I just realized I attached the wrong development build in my last post … could you try this development build instead?

Download link: https://storage.googleapis.com/releases.naturalcapitalproject.org/invest/3.7.0.post366+hc94dfedffddd/InVEST_3.7.0.post366+hc94dfedffddd_x86_Setup.exe

Thanks, and sorry about the confusion!
James

Hi! So I just updated my InVEST version and all my theat rasters have the same projection. Now I have a new error…InVEST-Habitat-Quality-log-2019-09-04–14_41_04.txt (1.5 KB)

Hmm … another user just posted this same error. I suspect it has to do with the formatting of your sensitivity table, so could you attach your sensitivity table so we can take a look?

Sure! Here it is:
sensitivity.csv (495 Bytes)

Ah! Ok, that’s really helpful … thank you! It turns out that there’s a bug early on in Habitat Quality that’s causing this error (due to an assumption it makes about the structure of the sensitivity table). Could you try this development build and make sure it runs through for you?

https://storage.googleapis.com/natcap-dev-build-artifacts/invest/jdouglass/3.7.0.post367+h11eff01a4d13/InVEST_3.7.0.post367+h11eff01a4d13_x86_Setup.exe

Thanks!

Hello! I keep having troubles with the Habitt Quality model… I’m using the latest version you recomended (3.7.0), and all my threat files are in meters and have the same projection as my LULC raster. I’m attaching the log: InVEST-Habitat-Quality-log-2019-10-07–17_25_03.txt (2.4 KB)

Thank you!

Hi @Lara,

Based on the error, it looks like there’s an issue in the quoting of fields in your threats CSV. The issue might become clearer in a text editor such as notepad than it will be in excel. If it isn’t clear there, could you attache your table so we can take a look?

Thanks,
James

I just looked at it in notepad but can’t find anything abnormal. Here goes the excel file: Threats.csv (206 Bytes)

Thanks for your help

Looks like the table had an issue with how it was saved: I was able to reproduce the issue by re-exporting the table from excel as the type “CSV (Macintosh)”. The attached table (Threats-export.csv (213 Bytes)) was created with type “CSV MS-DOS” and should work just fine.

The type used when exporting from excel matters a lot, so please do be sure to use either the normal “CSV (Comma delimited)” type or “CSV (MS-DOS)” type!

Ok, sorry about that… I already checked the table’s format… Now I’m having a different error related to a threat raster, the weird thing is that there is no raster with that name (Asent_c), the actual name is just Asent. I already checked that the names of the threat rasters match the names on both csv tables, and also changed the working directory three times and transfered all the input data again to new folders, and the same error keeps appearing… InVEST-Habitat-Quality-log-2019-10-08–11_19_57.txt (2.0 KB)

So, I converted all my threat files to raster datasets (TIFF), they all have the same projection as well as the LULC raster (which is also a TIFF), and now I’m having this error: Bounding boxes do not intersect. I was exploring the forum for some information and found another post with this subject, to work this around all they did was change the projection, but I already have everything in the same projection. What could this be? InVEST-Habitat-Quality-log-2019-10-08–13_37_13.txt (2.7 KB)

This error is happening because the model expects various threats to be available for the various scenarios. So, the Asent threat will need a corresponding Asent_c if evaluating the current scenario, Asent_b for the baseline, Asent_f for the future. The details for how threats need to be named is described in the HQ User’s Guide chapter under “Raster naming requirements”.

Honestly, it’s tough to say for certain without taking a close look at all of your inputs. Certainly mismatched projections are a usual culprit, but they do also all need to overlap as well if they are in the same coordinate system and projection. It is also possible that these inputs are projected into a coordinate system that GDAL doesn’t handle well. If this is still an issue, could you share these inputs with us so we can take a closer look?

Ok, I just send you all my inputs to your email. Thanks again.

The email rebounded. Do you have another email address?

It might be easiest to upload them to a filesharing service like dropbox or google drive … Stanford’s email does bounce emails with attachments that are too large.