DOC production in soil carbon module: Remove Carbon from TOTSOMC

[devarajun]

Scientific relevance
Integrate a representation of DOC production in terrestrial ecosystems within the soil column, and export DOC to the MOSART river network via lateral transport.

Related issue #1216

Scientific background
The Dissolved Organic Carbon (DOC) production from the soil organic matter carbon (SOMC) pools (depending on the decomposition rate of fast and slow pools) follows a first-order kinetics formulation depending on different carbon pools (see equation 4 in the article gmd-11-593-2018.pdf.

(1)

→ DOC production in soils (KgC/m2/day),
Suffixes → different pools (eg. slow/fast pools),
→ soil layers,
→ DOC production rate (per day),
→ Rate modifier due to soil moisture,
→ Rate modifier due to soil temperature,
→ Empirical factor for a decrease in C decomposition depending on soil layers,
→ Rate modifier due to clay and silt

Planned implementation

We target the soil biogeochemistry in CLM.
Eq. (1) produces a DOC flux and will remove carbon from the SOMC (soil organic matter carbon) either from each soil layer separately or from the total column. This implementation considers SOMC as the main source of DOC.

• Declare DOC as a flux type in the file SoilBiogeochemCarbonFluxType.F90

• Add a slim new module SoilBiogeochemDomMod.F90

At the moment, this module would have only one function: Implement Eq. (1) to compute lateral DOC fluxes from SOMC (same for all patches).

Following variables/parameters are needed

Input: soil temperature, soil organic matter carbon.
Output: DOC lateral flux
Parameters: DOC production rate, Empirical factor for a decrease in C decomposition, rate modifier due to clay and silt

Possible future extension?
Extend DOC production for each soil layer separately.
Add soil moisture variability effect on DOC production
Add spatial variation of clay and silt.
Add soil hydraulics.

Clarification

Does it make sense to add such a slim new module (similar to e.g. SoilBiogeochemNLeachingMod.F90)?
Or
Should we integrate Eq. (1) into an existing module that is altering SOMC (e.g. SoilBiogeochemDecompCascadeBGCMod.F90)?
Or
Any other thoughts?

People involved @devarajun @ziu1986 @kjetilaas @ecaas

[wwieder]

@devarajun thanks for letting us know what you're thinking here.

I'm not sure it's very useful in the long run to generate a C flux that removes DOC from the total column soil C as a diagnostic without conserving mass of the whole system. The structure here is identical to how the rest of the soil BGC code is working, so I'd encourage you to work within the existing modules. Here's a suggestion for how to do this.

First you'll have to decide if the generation of DOM is an additional decomp_k term that's coming out of each pool?

• Given the size of the fluxes, I'm not sure this is warranted... BUT if you do this you'll want the DOM decomposition flux to be an additional decomposition term added to the code it should go here:
  

  CTSM/src/soilbiogeochem/SoilBiogeochemDecompCascadeBGCMod.F90

  Line 938 in 3215d57

  ! calculate rate constants for all litter and som pools

• For example:
  • decomp_k(c,j,i_act_som) = (k_s1+k_dom) * t_scalar(c,j) * w_scalar(c,j) * &
    depth_scalar(c,j) * o_scalar(c,j) * spinup_geogterm_s1(c)

Second, you'll need to define the how the flux is handled by the transitions e.g. pathfrac_decomp_cascade or similar to the respiration fractionrf_decomp_cascade. The later will be easier to implement in my estimation.

• Given how you have things defined in your DomMod. I might just define a new flux for the DOM fraction of the decomp_cascade df_decomp_cascade and have this be 1e-4 of the total flux (or some other small number that's a parameter you define, just as the rf_decomp_cascade is handled).

Finally, you'll need to handle how you want to pass this flux around, but again I would trace rf_decomp_cascade around the code for examples.

This seems like the simplest approach that would be to not modify the decomposition rates, and add an additional DOM flux term that's just a fraction of total soil turnover. The advantage here is that it will let you conserve C, pass balance checks, and remain consistent with the existing code structure. It also avoids the creating of new temperature, moisture, and depth scalars that aren't used elsewhere in the code. I'm not sure if allows for the tuning of fluxes that you may ultimately want control over, but I'd work on building in that functionality after you're passing DOM fluxes to the river that conserve mass.

Happy to schedule a call to help clarify if it's helpful.

[ziu1986]

Thank you @wwieder for your opinion! I will discuss the choices with @devarajun today.
Sorry for dropping out of yesterday's call. My connection went down :-(.

[ekluzek]

Just to add a bit beyond what @wwieder already talked about in terms of thinking about the software side of things. And to add some of our thinking that we discussed this morning. It's good to think about if something should be in its own module/file or if it goes integrated into existing modules. There's good reasons for doing either one. But, if it's something that's really part of the data in existing modules -- it should likely go inside existing modules. It is still good to have it in it's own subroutine (especially when you figure that subroutine is going to be developed further such as in this case). If it has a lot of it's own data that's new and different from existing modules it likely makes sense that it should be a new module. If it's in it's own module, but only operating on data outside the module -- you have an unneeded outside dependency you might as well put it inside the module already operating on that data.

One way to look at this is to make data as local as possible. If you can have the subroutine in the module that defines the data that it's operating on that's something desired. Look at it as the module that defines the data is the expert on that data, and if you can keep subroutines that operate on it within the same module that keeps that expert knowledge in one place and in one file. It's harder to debug code with a lot of global data because if something can be changed anywhere in the code -- you have to look through the entire code. But, if you know data is confined to one module and it can only be changed within that module you have a better chance of figuring out where it might change.

[devarajun]

Thanks a lot, @wwieder and @ekluzek for your inputs. I am looking into those options you have mentioned to better understand myself and get back here with further questions if any.