Carbon Storage Rounding Confusion

hasolak825hasolak825 Member
edited February 2014 in Terrestrial Models
When running the model with the Harvested Wood Product option selected, there is some conflicting information on rounding within the Harvested Wood Product Algorithm. In Equation 1, the documentation reads:

“…where is measured in Mg ha-1, is short for “Year of current land cover”, t indexes the number of harvest periods, and indicates that any fraction should be rounded up to the next integer value.”

This indicates that when calculating the maximum value of t , one should round up if a fraction results from the equation within the parentheses. Later on, the equation for Future Harvested Wood Product (Equation 5) reads:

“…where the function f is as before. Recall that if (yr_cur + yr_fut) / 2 results in a fraction it is rounded down. Also note that equation (5) does not include a harvest that is scheduled to occur in the future year; this harvest’s carbon isin situ in this accounting.”

In this instance, the equation for Future Harvested Wood Product says to round up, indicated by the “ru ”. However, the documentation says to round down and to “Recall” this (I am assuming from the only other instance of this - equation 1).

When hand calculating this value for comparison with model output values from both Idrisi and InVest software, it seems that for each instance that Current Harvested Wood Product is calculated, Idrisi rounded up while InVest rounded down. I know this as when I test resulting values and round up in my equation, my hand calculation matches Idrisi exactly. When I round down in my calculation, my hand calculation matches InVest exactly. When calculating Future Harvested Wood Product in Equation 5, it appears that both models rounded up.

I am wondering if InVest meant to round up or down here, and what the logic is behind what option they chose. Thank you.
780 x 61 - 3K
863 x 92 - 4K
Post edited by kglowinski on


  • Hi there - does anyone know of a solution to this question? Thank you!
  • Thank you for bringing this error to our attention and I apologize for the delay in response.

    The function should be to round up since the parcel rotation (in years) is then adjusted by -1 (equation 1). It appears the 2.0 ArcGIS version of this model uses the normal rounding function, which will round up or down depending on the fraction.

    For equation 5, I believe the reference to rounding down is either a typo or may be poor wording since the fraction is "technically" rounded down (rounded up then adjusted by -1). Thank you for pointing out this inconsistency and I will make a note to correct it in the InVEST User Manual.

    The standalone 3.0 Carbon model should use the appropriate function. Could you please try running your data using that model and let me know if that is consistent?

    Thank you for your time and consideration.

    Brad and James
  • Hi Brad and James,

    Sorry for the late response, I wanted to make sure I re-ran the model using the 3.0 standalone and checked the values before I wrote back to you.

    From what I can see from the values I have extracted in the outputs, the algorithm still appears to be rounding down rather than up. For example, if yr_cur-startdate/freq_cur = 5.6, rounding up this number becomes 6 and 1 is then subtracted from that number to give you a value of 5 for t. Based on what I understand from your last response, my hand calculations and from the value of my test pixels, it appears to me that if yr_cur startdate/freq_cur = 5.6, Invest is then rounding down to 5 and then subtracting 1 to give a value of 4 for t. I can see this as when I round down in this manner, my hand calculations match exactly that of your model's output for a given pixel.

    I was originally using the standalone 2.5.6 version of Invest, but the values have not changed with the use of the 3.0 model. Let me know what you think.

    Thank you


  • jdouglassjdouglass Administrator, NatCap Staff
    Hi Hayley, Sorry again for the delay. We're working on this and hope to get back to you soon.

  • Great, thank you.
  • jdouglassjdouglass Administrator, NatCap Staff
    We found the bug! It was indeed on our end, and had to do with integer division (which in python 2 rounds down to the nearest integer) instead of correct floating-point division. The fix to the windows executable will go out in the next release.

    If you need to use a corrected version of the Carbon model, you could try a development build from this link: [76cd28019086]_x86_Setup.exe
  • Glad to hear you resolved the issue. Thanks for looking into this!
This discussion has been closed.