My question is about the difference in total carbon -C- stock given in the output report of InVEST (Total cur) and the sum of four C pools.
I have used land use and land cover raster, the table of C pools in CSV format and run the model. It gives the Cabove, C below, Cdead and Csoil results without any problem. However, once I calculate the total amount of carbon in each pool by multiplying the ‘value’ and ‘count’ values of each pool (for this calculation, I used Properties>Symbology>Unique values of each TIF in ArcMap), the result is different than the number given as an output HTML document. Does anyone know what could be the reason of this difference?
How different is the result that you get, versus the output of the model? Could it be explained by the input carbon pools being given in MgC / hectare, versus the output values being given in MgC / pixel?
Thanks for your reply.
The sum of Cpools is around 3935591.4 Mg C/ha while the output value is 5758941.4 Mg C/ha.
I also realised that the difference between those two values which range between 1823350.023 to 1701313.55, gradually decreases in the total C calculation of different years (2000, 2006, 2012).
What you say could be the reason but previous time I did not have this problem, the values were coherent.
I’m not too familiar with ArcMap, but I think the Unique values calculation maybe isn’t doing what you want it to. Each carbon pool TIF shows the carbon stored in that pool at each pixel. So to get the total carbon stored in a pool, you would need to sum the entire raster for that pool. sum(c_above_cur.tif) + sum(c_below_cur.tif) + sum(c_dead_cur.tif) + sum(c_soil_cur.tif) should equal the total current carbon in the InVEST output report.
There should be some sort of statistics tool that will calculate the sum of the raster for you. In QGIS you can do it with Processing > Toolbox > Raster analysis > Raster layer statistics > Run. In ArcMap maybe you can use the Raster Domain tool to get a polygon outline of the raster, and then the Zonal Statistics as Table tool to sum the raster over its entire area.
Sorry to chime in here, but it’s also worth noting that the Carbon model converts the per-hectare carbon pool volumes to account for the area of a pixel. Concretely, if the input table values are in units of megagrams per hectare, the pixel values of the carbon storage maps produced by the model are in megagrams per pixel.
So unless your pixels have an area of 1 ha, I’d expect the output pixel values to be a bit different from the sum of the carbon pool values!
Thank you so much for your suggestion. I calculated the sum of raster both in QGIS and ArcGIS by following the steps you mentioned. Both have the same result with what I have found by using TIF and all three are different than the output value of the report. Could the HTML module of the model be problematic?
Thank you pointing out this issue! I think it is the cell size what you mean, which is given as (X, Y) 5, 5. Do I need to change it to 1 ha and repeat the calculation?
That is interesting. We have some extensive tests for the model so we are pretty confident that it works, but bugs are always possible! If you don’t mind sharing your data, you can send it to me and I will try to replicate the issue and figure out what is going on. You could upload it to google drive and share the link here, or you could email it to me privately at esoth@stanford.edu.
I have the same problem. I´m using the InVEST Carbon model for my bachelor thesis. I calculated the total carbon stock by multiplying the number of cells with the matching carbon value and sumed up the results. My Result is 477657009.63 Mg C. The InVEST HTML output is 477656994.51 Mg C.
I also used the arcGIS tool zonal statistics to calculate the amount of C per landuse for the InVEST output (total cur). I sumed up this results too and also got a total of 477657009.63 Mg C as well.
Does anyone know what could be the problem?
Could you attach your carbon output raster to this thread or else send it to jdouglass@stanford.edu? I’m pretty sure we can improve the precision of that number in the carbon report and I’d like to try. Using your model output will help make sure that the issue is resolved.
The longer answer to your question is that these two numbers you mention, 477657009.63 and 477656994.51, which do of course have a different value are numerically quite close. Any time you’re dealing with floating-point numbers in a program, there’s always some margin of error, and this error is more noticeable when aggregating lots of pixel values as we are here.
In this case, these two numbers have an absolute difference of about 15 Mg C, but a relative difference of about 1e-7, which is quite small (and quite good as far as numerical error goes).
If you wanted to test this numerical closeness in python, you could do:
>>> import math
>>> math.isclose(477657009.63, 477656994.51, rel_tol=1e-7)
True
So, I don’t think anything is technically broken, but this is clearly a mismatch between a more precise summation and the number in the report and it’d be great to see if we can fix this so that the report contains the sum you expect.
Great, thanks @Maylin ! In looking at the tot_c_cur.tif raster you had sent, I was unable to reproduce the 477657009.63 value you mentioned, even when counting up all of the unique pixel values and multiplying by the pixel count.
That being said, I’ve put together a development build (download here) that does a higher-precision summation for the sake of the report. Could you try that out and see how it compares?
I used your development build and got a html result of 477657019.94 Mg C. I also used the tool zonal statistics on the output and got a result of 477657020.09 Mg C. The Results are much closer now. Thank you!
Why is the result different from my manually calculated result? I multiplied the raster cells with the carbon values and sumed it up. I thought thats how the carbon model calculates it´s results too. Could you send me the formula of how the carbon model calculates it´s results?
Thanks a lot for helping!
Because as good as computers are at calculating things, there are limits to the accuracy. Without knowing more about how ArcGIS or your calculator are implemented, I’d guess is that they’re doing something ever so slightly different from InVEST causing slightly different results. That’s fine … remember, we’re talking about a difference of <15 Mg C compared to over 477 million Mg C, which, while different, is an inconsequential numerical difference.