elm, understanding components of column level summary stocks

[rgknox]

I'm working with @ckoven and @rosiealice to make some of the column-level carbon state summary variables available with FATES. Mainly I want to make sure I understand what are the differences between and the ingredients in totecosysc, totcolc and totabgc.

Defined here and filled here.

       this%totecosysc(c) =    &
            this%cwdc(c)     + &
            this%totlitc(c)  + &
            this%totsomc(c)  + &
            this%totprodc(c) + &
            this%totvegc(c)

       this%totcolc(c) =       &
            this%totpftc(c)  + &
            this%cwdc(c)     + &
            this%totlitc(c)  + &
            this%totsomc(c)  + &
            this%totprodc(c) + &
            this%ctrunc(c)   + &
            this%cropseedc_deficit(c)

        this%totabgc(c) =       &
            this%totprodc(c) + &
            this%seedc(c)    + &
            this%ctrunc(c)   + &
            this%totpftc(c)

I see that ecosystem carbon uses "totvegc", while total column carbon uses "totpftc" to incoporate the vegetation component. These column level arrays are derived from are patch-level summary variables of the same name that are up-scaled to column level, here.

Here are where the patch-level variables are updated:

       ! total vegetation carbon, excluding cpool (TOTVEGC)
       this%totvegc(p) = &
            this%dispvegc(p) + &
            this%storvegc(p)

       ! total pft-level carbon, including xsmrpool, ctrunc
       this%totpftc(p) = &
            this%totvegc(p) + &
            this%xsmrpool(p) + &
            this%ctrunc(p)

Seems like xsmrpool and ctrunc are pools used to accomodate the model needs. xsmr makes sense, and I'm guessing that xsmr is a negative number? Column level ctrunc is associated with decomposition, and patch level ctrunc seems to be associated with photosynthesis. I was first surprised that patch level ctrunc and column level ctrunc were both included in col_cs%totcolc, but they are different terms.

    real(r8), pointer :: xsmrpool           (:) => null() ! (gC/m2) abstract C pool to meet excess MR demand
    real(r8), pointer :: ctrunc             (:) => null() ! (gC/m2) patch-level sink for C truncation

I guess my question is, why do you include truncated carbon and xsmr in col_cs%totcolc and not col_cs%totecosysc? My interpretation is that totecosysc is a better variable to associate with things observed in nature and associated with real-world mass pools, whereas totcolc is a better variable to use for book-keeping total mass.

I suppose for fates, since we don't have xsmr pools, we would just add the column level truncation term to our totecosysc term to get totcolc?

if (col_pp%is_fates(c)) then
       this%totecosysc(c) =    &
            this%totlitc(c)  + &
            this%totsomc(c)  + &
            this%totprodc(c) + &
           this%fates(nc)%bc_out(s)%veg_c_si + &               ! Live fates vegetation
            this%fates(nc)%bc_out(s)%litter_cwd_c_si + &     ! all fates-side litter (ie all litter we haven't passed to ELM yet)
            this%fates(nc)%bc_out(s)%seed_c_si m  ! fates-side seed

       this%totcolc(c) =       &
            tthis%totecosysc(c)  + & 
            this%ctrunc(c)   + &

Also, I'm confused by col_cs%totabgc:

real(r8), pointer :: totabgc              (:)    => null() ! (gC/m2) total column above ground carbon, excluding som

I thought its component totpftc, which contains totvegc, which contains dispvegc, has the below-ground component of vegetation such as living fine and coarse roots. So it contains below-ground live vegetation, and above-ground products, but not above-ground litter. We can try to reproduce something similar in FATES but I need to know the rationale.

 this%totabgc(c) =       &
            this%totprodc(c) + &
            this%seedc(c)    + &
            this%ctrunc(c)   + &
            this%totpftc(c)