FATES tests fail with MIMICS active

[slevis-lmwg]

Brief summary of bug

On izumi I get the error:
SoilBiogeochemDecompCascadeMIMICSMod.F90 line 852: Reference to undefined POINTER

On cheyenne the error feels more helpful:
SoilBiogeochemDecompCascadeMIMICSMod.F90 line 1111: Index '1' of dimension 1 of array 'ligninnratioavg' above upper bound of 0

ERS_D_Mmpi-serial_Ld5.1x1_brazil.I2000Clm50FatesRs.cheyenne_gnu.clm-FatesColdDef
ERS_D_Ld5.f10_f10_mg37.I2000Clm50Fates.izumi_nag.clm-FatesColdDef.0202-170916iz_nag

General bug information

CTSM version you are using: ctsm5.1.dev073-79-geba82445d

Configurations affected: soil_decomp_method = 'MIMICSWieder2015'

[slevis-lmwg]

ligninnratioavg is declared in CNVegCarbonFluxType.F90
I get the sense that we don't exercise this code when FATES is active.

[slevis-lmwg]

CNDriverMod.F90 has subroutine CNDriverSummarizeFluxes where we call both soilbiogeochem_carbonflux_inst%Summary and cnveg_carbonflux_inst%Summary.

EDBGCDynMod.F90 has equivalent subroutine EDBGCDynSummary where we only call soilbiogeochem_carbonflux_inst%Summary.

[slevis-lmwg]

We calculate ligninnratioavg in subr. Summary_carbonflux in module CNVegCarbonFluxType and do not call this subroutine when FATES is active, as explained in my previous post:

this%ligninNratioAvg_col(c) = &
             (ligninNratio_leaf_col(c) + ligninNratio_froot_col(c) + &
              ligninNratio_cwd) / &
              max(1.0e-3_r8, leafc_to_litter_col(c) + &
                             frootc_to_litter_col(c) + &
                             soilbiogeochem_decomp_cascade_ctransfer_col(c,i_cwdl2))

The formula uses column copies of leafc_to_litter_patch and frootc_to_litter_patch. Neither the column nor the patch copies are available with FATES active as far as I can tell. So I think we may need a refactor to make these variables available when FATES is active.

[slevis-lmwg]

Though FATES doesn't do nitrogen, right? Maybe then for now we set ligninNratioAvg_col = a reasonable constant when FATES is active?

[wwieder]

Previously I've set ligninNratioAvg to a pft specific value for C only runs. Is this a possibility for FATES too? Can we just make them hard coded or put them on the parameter file. Either way, we should clarify that the values are only used for C-only simulations.

[slevis-lmwg]

Previously I've set ligninNratioAvg to a pft specific value for C only runs. Is this a possibility for FATES too? Can we just make them hard coded or put them on the parameter file. Either way, we should clarify that the values are only used for C-only simulations.

This should work. Let me know values by pft, and I will give it a try. Then we can iterate on my implementation as needed.

[wwieder]

I think we can start with lignin and N values from Table 1 in this paper. Let me know if there's uncertainty in how to map the pfts listed here to the CLM pfts
https://bg.copernicus.org/articles/9/565/2012/bg-9-565-2012.pdf

[slevis-lmwg]

Thanks @wwieder, I will look into this today.

I wanted to include a helpful comment @rgknox made at stand-up yesterday:
Beyond the above fix intended for when use_fates = .false., @rgknox said that getting MIMICS to work with FATES will require a bigger refactor. @rgknox recommended not worrying about it at this time.

@rgknox pls correct me if I misunderstood.

[slevis-lmwg]

Beyond the above fix intended for when use_fates = .false., @rgknox said ...

Correction: The above fix is for when use_fates = .true. and it leaves the more complex refactor for later.

[slevis-lmwg]

@wwieder
we also need values by pft for annsum_npp_col because this is also declared in CNVegCarbonFluxType.F90

[rgknox]

cc'ing @ckoven and @rosiealice
@slevisconsulting and @wwieder , that is my sense, but I need to learn more about mimics and what types of boundary conditions it requires from FATES. I also shouldn't assume what work and efforts have already been done to enable compataibiity between these two models.
In the stand-up meeting, I was alluding that for FATES coupling with century (its still century right? :/) and existing decomposition soil BGC, we bypass some code on the CLM side that would typically be run when use_cn is true, and instead use a simplified version of the code maintained in a file called EDBGCDynMod.F90. Ideally, we would want FATES to coordinate with all of the native code for decomposition (and nutrient dynamics) on the CLM side, without having our own simpflified (or different) code to handle these things. I think it also would be good to walk through the sequence of physics events, in all things BGC (decomp and nutrient), and re-evaluate how fates needs to accomodate it and vice-versa.. maybe the key phrase here is wholistic approach?
Yeah, so the broader refactor I was thinking of would touch on this last point. To avoid the code-tacked-on-code apacolypse, it seems a good idea to consider fates connection with mimics at the same time we refactor fates-century/existing bgc model. Does that make sense?

[ckoven]

@wwieder agreed with @rgknox we should sit down and discuss what MIMICS needs to know about its litter inputs and figure out how to reintegrate FATES with nutrients into the full sets of decomposition schemes rather than the current way that bypasses all the nutrient code.

[wwieder]

Agreed, this is a good conversation to have.
What kind of timeline makes sense for this? I ask because MIMICS is functional with CTSM-BGC, but still need work related to spinup that will actually make it scientifically viable. I also need to spend more time evaluating the current configuration of the model. In the short term should we just not allow a MIMICS-FATES simulation to even occur, or are there smaller things we should consider now on the MIMICS /HLM side that we should be considering now for FATES?