HQ error with value

hello learned scientists,
I do need help to resolve this tough error.
I have been working on this (Habitat Quality) ecosystem service and in the process of running the model, it got stuck at the point in which it generated an error stating that folloring land corer codes rere found In your landeorer resters but not in your sensitivity rable. Check your sensItIvi ty rable tosee if they are missIng:056 85240 255See the log for details.
Please how do I go in resolving this. I have attached the accompanying error message to this.
Thank you for the attempt.

Welcome, Emily.

I canā€™t actually see your logfile, I guess it did not upload successfully. But your error message has helpful information. It suggests that your sensitivity table needs rows for those ā€˜missingā€™ landcover pixel values. All values present in your raster must be listed in the table. So you can either update your sensitivity table with rows for these values, or you can reclassify your raster so that it does not include any values that are not present in the table.

If that does not work, please try again to upload your logfile.

dear dave,
Thank you very much for your help. I 'll try it now and see if itā€™s useful. I 'll get back to you later

hello daveļ¼Œ
I managed to run my model successfully, but I felt that my results were not quite correct. I felt that it was my input that was wrong, but I did not find the specific reason. Do you know what this is? What I do is habitat quality.

Well I donā€™t have the experience with habitat quality to say if these results are correct or not, but perhaps someone else around here does.

At any rate, what specifically makes you think the results are not correct?

helloļ¼Œdaveļ¼Œ
Thanks for the response.I ran the simulation data, and I found that the results of the simulation data were very different from my results, and I saw that the results of other peopleā€™s running were in the same range of 0 to 1 as the simulation data.I donā€™t know if I entered the data in the wrong format or something else.

Hello Emily,
I also met the same problem when I run the Habitat Quality. The error message is "the following land cover codes were found in the sensitivity table, check the sensitivity table to see if they are missing:255 ", just similiar with your problem. And I want to know how you figured it out and run the model successfully. I check my sensitivity table and the 255 doesnā€™t exist and also the land cover raster file.
Hope you can help me and thank you so muchInVEST-Habitat-Quality-log-2019-06-11--07_26_07.txt (1.4 KB)|attachment

Hi @zouxiaohan, I believe we improved this error in InVEST 3.7.0, the latest version. Could you make sure youā€™re running the latest version? If you are, could you try re-uploading your logfile? It didnā€™t quite attach to your post.

Thanks!
James

@zouxiaohan The 255 value might be a NODATA value. When I created my rasters and ran the model with the sensitivity table I made, it also gave me that same error. After taking an extra look the 255 was on the Attributes table of the raster and manually looking at the raster layer, I could see that it was representing a NODATA value that was probably overlooked when creating a mosaic or something. Put that value in your sensitivity table and then give it a weight of zeros across the threats and it should solve the error, itā€™s what I did and it worked.

  • Nadia
1 Like

@Emily Did you reclassify your land cover map to have the missing value or put the missing value in your sensitivity table? I assume you plugged in the missing value into your sensitivity table. It really depends on the number you assigned to each weight of threat on what you see in your output. If that missing value only represented a NODATA areas then in your sensitivity table they would have weights of 0 for the threats. Perhaps the assignment of those numbers is why you arenā€™t seeing the results you were expecting?

  • Nadia

Hi @jdouglass, I tried to use the InVEST 3.7.0 to run the HQ model with my own dataset. It worked well and the quality map and deg_sum map came out as the results, but I found that the range of deg_sum map was not from 0 to 1, you can see from the picture. Do you know what the problem is? I prepared the dataset according to the Userā€™s guide and I have no idea whether I input the data in a wrong format or something else.Thank you again for your help!

Hello, @nadia , Thanks for your suggestion, I download the latest version of InVEST 3.7.0 to run the HQ model and the problem wasnā€™ appear this time, but something wrong with the results that the range is not betweent 0 and 1, and I have no idea what makes the problem. Do you know what this problem is?
Thank you for your help!

~Zou

Hi @zouxiaohan, sorry about the delay here. I donā€™t immediately know whatā€™s going on with this. Could you attach your inputs (file sharing services like google drive or dropbox are probably your best bet) to this thread so I can take a look?

Thanks!

Hello Nadia,
Thanks for your message, your answer help me a lot.I would try it. Hwever,what is the definition of those non-research areas? That is, how to assign it to a non-research area.

Hey @Emily Iā€™m glad to hear the suggestion helped. Iā€™m not sure what you mean by defining the ā€œnon-research areasā€, would you mind rephrasing the question? If I am understood correctly, non research areas are locations that are not the focus for your project. They are areas that there contain no data as it isnā€™t the target area that you are studying. What are you planning to assign in those ā€œnon-research areasā€?

  • Nadia

Hello,@jdouglass, Thanks for your reply and help. I can directly send my input data of HQ model to you and please help me find out whatā€™s wrong with it. I run many times and tried to modify the threat_map values, but came out with the same result.HQ model input.zip (725.1 KB)
Thank you again and looking forward to your reply.

Zou Xiaohan

Hello Everyone,
I am working on the HQ (version 3.7) model as well and am currently experiencing the same problem as @zouxiaohan. The range of the habitat degradation seems unreasonable (-3.40282e+38 and 3) whereas the habitat quality scores are between 0 and 1. Is this related to the NoData values (which I considered zero) in the model or it has some other reason?
These results were attained based on considering the K equal to 0.5.
The point is habitat degradation scores are translated to habitat quality scores based on the equations in the userā€™s guideline
ā€œA grid cellā€™s degradation score is translated into a habitat quality value using a half saturation function where the user must determine the half-saturation valueā€.
Please let me know if there is a point I have not considered in my model.
Thanks

Hi everyone,

Sorry for the delay on this. We recently patched an issue with Habitat Quality that will be included in the next release of InVEST that might address the numerical issues mentioned.

@Aidin and @zouxiaohan , could you try this development build and see if that fixes the issue for you?

Hereā€™s the download link: https://storage.googleapis.com/releases.naturalcapitalproject.org/invest/3.7.0.post241%2Bhe520675466a4/InVEST_3.7.0.post241%2Bhe520675466a4_x86_Setup.exe

Thanks,
James

Hello @jdouglass and thanks for the reply ,
I have downloaded it and run my model with the new development build, but got the same results.
I have a question though. Is it possible for degradation results to be negative? Based on what I understand from the Dxj (xj are subscripts) formula and the negative values that irxy (rxy are subscripts) can be assigned as the impact of threat sources which are distance-dependent, I think the degradation scores can be negative. In other words, in my model many pixels are located beyond the maximum effective distance (0.1 km) that I considered for my sources, thus making the impact scores negative which in turn makes the degradation scores negative in those very cells. These values in my model vary between Low : -1.45436e-16 and 0.408163.
Looking forwards to your reply
Thanks
Aidin

Hello, in this case, the negative values you mention are really, really small ( -0.000000000000000145436 in decimal notation), so small that they can be explained by floating-point numerical error and safely regarded as having a value of 0.

To the best of my knowledge, degradation values should range between 0 and 1.