Hi, I am using the Coastal Blue Carbon model and am filling out my carbon_biophysical table. I’ve noticed that the Global IDB table (provided), on the SaltMarshSoil tab, has a column called T_CO2e_ha. I assume this is a calculation for carbon storage? Is this is correct? If so, what is the formula you are using to calculate it? For example uculet, BC states that it has 623.33 T_CO2e_ha. This was calculated using, =(0.0210^610^444)/(1210^6). What is this calculation? I understand that the 0.02 is coming from the cited article: Chmura, G. L., S. C. Anisfeld, et al. (2003). “Global carbon sequestration in tidal, saline wetland soils.” Global Biogeochemical Cycles 17(4): 1-12. However, when you visit this article, many of the referenced soil densities that are used in the Global IDB table are taken from unpublished data, including the uculet, B.C. reference…I was going to use the Chmura data however, now that I see that it comes from unpublished or untracable data, I would like to use alternative storage values but am very curious as to what is the formula applied to the soil density to find carbon storage?? For example, where does the 44 and the 12 come from in the calculation?
This is a good question. I don’t know about the origins of that table but I will ask our science team for more info.
Since the model does not use that table I don’t think it should be in the sample data… they are intended only to illustrate the format of inputs. If the data in that table is useful and correct we should publish it in a different venue with more documentation. I would ignore it unless we can get an explanation from the table’s author.
As a caveat, I did not make this table, I’m just familiar with the Blue Carbon model. In that equation, 44/12 is the conversion rate for going from elemental carbon (given in the column gC_cm3) to CO2 (given in column T_CO2e_ha). The whole equation should be a conversion from gC_cm3 to T_CO2e_ha, although I don’t know what the thinking was for converting cm3 to hectares.
It’s useful that we provide this list of resources, but we should also be explaining any equations used. Unfortunately, I think this was compiled quite a few years ago, so the authors have probably moved on by now.
I’ll also applaud you for critically evaluating these values and sources before using them. If the quality of the source data is not adequate for your needs, then don’t use it. But many times we don’t have better data, and for some needs, unpublished data for our local site is considered better than published data from elsewhere.
Thanks for your explanation Stacie. That helps me get a better understanding of those values.
I agree, that there should be some sort of explanation behind the resources and equations used. Perhaps metadata or an assumptions list. If the values are for illustrative use only then that should be stated. Perhaps that is documented somewhere, but I did not see it in my reading.
If anyone comes across anymore details on this, please send it my way!
In general, this is intended to provide a pre-compiled literature search for model-specific values, and from that perspective is not only for illustrative use, we do actually hope it’s useful for helping users parameterize their own models (although it’s a few years old, so it’s still worth doing your own lit search to see if there are new studies for your area).
That said, each individual source will have differing methods etc, so we also expect people to read the original source and critically consider whether it’s appropriate for their use or not. Of course, you are also welcome to re-calculate the model parameter yourself based on the lit source information.
Hello, about the blue carbon model, can you provide the data information required by version 3.10.2? The blue carbon model of version 3.10.2 cannot be run according to the information prepared in the user manual of version 3.2.0. I wonder if I am the only one who has encountered this problem, and I am a little confused.
Here are the release notes for the refactored CBC model:
Refactor of Coastal Blue Carbon that implements TaskGraph for
task management across the model and fixes a wide range of
issues with the model that were returning incorrect results in
all cases.
Corrected an issue with the model where available memory would
be exhausted on a large number of timesteps.
In addition to the execute entrypoint, another entrypoint,
execute_transition_analysis has been added that allows access
to the transition analysis timeseries loop at a lower level.
This will enable users comfortable with python to provide
spatially-explicit maps of accumulation rates, half lives and
other parameters that can only be provided via tables to
execute.
Snapshot years and rasters, including the baseline year/raster,
are now all provided via a table mapping snapshot years to the
path to a raster on disk. The baseline year is the earliest year
of these.
The model’s “initial” and “lulc lookup” and “transient” tables
have been combined into a single “biophysical” table, indexed by
LULC code/LULC class name, that includes all of the columns from
all of these former tables.
The “analysis year” is now a required input that must be >=
the final snapshot year in the snapshots CSV.
Litter can now accumulate at an annual rate if desired.
The model now produces many more files, which allows for greater
flexibility in post-processing of model outputs.
Hi @wenjing , Just to add on to @dcdenu4 's good overview, the main difference in inputs between earlier versions of the InVEST Coastal Blue Carbon and the InVEST 3.9+ version of CBC is the landcover snapshots table, which replaces the older, clunky set of inputs in the UI where you would “add another” and everything had to match up. The other tables used as model inputs should be the same.