Coastal blue carbon output questions

NatCap Software Support
#1

Hello,

I’m running the coastal blue carbon model (3.8) to investigate future carbon fluxes with sea level rise (reflecting a combination of processes including upland marsh migration, marsh drowning, and vertical accretion of marshes). The model ran successfully, but I have a few questions about the outputs.

The carbon_emissions_between_2050_and_2120.tif output looks reasonable for most of the habitat types, but a very high value of 23922938 for the pixels that represent marsh that drowned due to SLR between 2050 and 2120. This value is much higher than expected (the carbon stock at 2050 for the same pixels is 0.000891, so they shouldn’t be able to emit more than that, right?).

I’m confused about the timing of transitions and how that is reflected in the carbon accumulation and emissions rasters. I thought that transitions occurred in the year they appear in a habitat raster - for example, if a non-blue carbon habitat in the baseline raster transitioned to a blue carbon habitat in 2050, then that pixel wouldn’t accumulate any carbon between the baseline year and 2050. However, the carbon accumulation raster from the baseline to 2050 has positive values for these types of pixels that is the same as the value for pixels that started out and remained a blue carbon habitat. Similarly, the carbon stock at 2050 raster shows that these pixels have some carbon stored, even though I would expect them to have 0 carbon stock until the next timepoint after they transitioned to a blue carbon habitat. Is this something that has changed from previous versions of the model?

Thanks; I can share screenshots or outputs to illustrate either of these if that would be helpful.

#2

Following up on this to see if someone can help! I’m attaching my preprocessor and core model logs, preprocessor outputs, and the carbon emissions raster where the very high values occur.

Any insight on what is causing the extremely high emissions values between 2050 and 2120 would be appreciated.

InVEST-Coastal-Blue-Carbon-log-2020-05-04–14_31_22.txt (19.0 KB)
InVEST-Coastal-Blue-Carbon-Preprocessor-log-2020-05-04–12_22_04.txt (2.0 KB)
outputs_preprocessor.zip (2.3 MB)
carbon_emissions_between_2050_and_2120_test.zip (771.4 KB)

#3

Hi @kwarnell,

Sorry about the delay here!

The high value of 23922938 in the carbon emissions sounds like a bug to me, though I’m not entirely sure what might be causing it.

From what I can tell, your understanding of the model is correct, and if you’re seeing positive values in the outputs, it’s quite possible that there’s a bug! I see that you’ve already attached a few rasters and logfiles … are the preprocessor outputs the ones you were using when you observed this behavior? And if so, which raster in that zipfile corresponds to which year?

Thanks!
James

#4

Hi James,

No problem; I see a new version was just released so I’m sure you’ve been busy.

The preprocessor outputs are what I used as inputs for the core model when I got these results. aligned_lulc_0.tif is the baseline year (2010), aligned_lulc_1_low.tif is 2050, and aligned_lulc_2_low.tif is 2120.

Thanks for looking into this!

#5

Great thanks! I’ll look into this and get back to you soon.

#6

Thanks. I was just going back through the user’s guide to make sure I didn’t miss anything, and may have found the issue. In the Step 1: Preprocessor, outputs section, the guide says that “disturbance is in integer percent.” However, under Step 2: The main model, the instructions for the carbon pool transient variables table says “The ‘disturbance’ values must be given as a decimal percentage of stock disturbed when a transition occurs away from a particular LULC class.”

I was using integer percent (e.g. 25) in the transient variables table, as described in the preprocessor (and I think in accordance with how this worked in previous versions of the model). The description later in the user’s guide makes me think that I should be using decimal percentages (e.g. 0.25) instead. Can you confirm which format is correct for the disturbance field?

#7

Hi @kwarnell, thanks for digging into this! Yes, I can confirm that the disturbance values in the main model should be in floating point percentage values between 0 and 1. This is in contrast to the disturbance values in the preprocessor, which are indeed integer percentage values. This also makes sense given the emissions equation, were a positive integer disturbance value would lead to a numeric result that is orders of magnitude greater than what was intended.

If that doesn’t do the trick, let us know! And if not, could you provide your LULC lookup table so I can try to reproduce the results?

Thanks,
James

#8

Hi @jdouglass, thanks for confirming that. I ran the model again after adjusting the disturbance values used in the main model to be floating point percentage values, but still got the same result. The emissions values for the first time period (baseline 2010 to 2050) look reasonable, but for the later two time periods (2050 to 2120 and 2120 to 2140), the emissions are many orders of magnitude greater than expected.

My LULC lookup table is attached; let me know if you need anything else to reproduce the results.

NC_LULCLookup.csv (275 Bytes)

Thanks!
Katie

#9

HI @kwarnell, just wanted to let you know that I’ve reproduced this issue on my end and am working on a fix. This turned up a really interesting bug on our end, so I hope to have a development build to you soon.

#10

OK! @kwarnell could you try out this development build and see if that corrects the issue for you?

https://storage.googleapis.com/natcap-dev-build-artifacts/invest/phargogh/3.8.0.post595+g34696bd5/InVEST_phargogh3.8.0.post595+g34696bd5_x86_Setup.exe

Thanks,
James

#11

Thank you! I’ll see if I can get to this by the end of the week.

#12

Hi @jdouglass, I’m testing the development build and got an error when running the main model: could not convert string to float. My log is attached; wondering if you could point me toward which input is likely to be causing this issue.

Thanks!
Katie

InVEST-Coastal-Blue-Carbon-log-2020-05-26–16_30_05.txt (5.5 KB)

#13

It’s hard to tell exactly from the error message, but the first place I’d check would be that all of your halflife values in your input tables are numeric and not written as blank cells.

The second thing that I’d check is that there aren’t accidentally any blank lines that have been added to your table. The easiest way to check this is to open your table in notepad or a similar text editor and just make sure that there aren’t any lines without field values.

If that doesn’t do the trick, could you send the input tables you used here so I can take a closer look?

#14

Thanks; looks like the issue was a blank cell. The model ran successfully, but I still have a few questions about the outputs:

  • I’m still seeing the issue with timing of transitions that I described in my first post. The emissions raster for the first time step (2010-2050) shows emissions in areas that transition from marsh to open water in 2050, which from my understanding of the model shouldn’t show up until the next time step. Similarly, the carbon accumulation raster for the first time step shows accumulation in areas that transition from non blue carbon classes to marsh in 2050, which also shouldn’t show up until the next time step. Did you see that effect when testing the model?
  • The carbon emissions output rasters for each set of years don’t have the very large values I was seeing when using the previous model version. However, the total net carbon sequestration raster symbology setting shows a minimum value of -239229. When I ran a statistics tool on the raster, I got a minimum of -0.19, which is much more reasonable. This might just be a symbology issue, but the very large negative value makes it hard to visualize the results without displaying unique values.

Thanks for your help; let me know if you need to see any particular supporting files.