Needs for prescribed land use change (changing crop areas)

[billsacks]

This issue captures thoughts related to what will be needed to be able to model land use change (changing crop areas, or changing glacier areas, etc.) with CLM-FATES. This is a general, long-term enhancement, which should be viewed as a way to capture some thoughts, rather than an issue per se.

[billsacks]

@rosiealice points out that, at a high level, the biggest need is for the host model to be able to tell FATES that its column area has changed, and then for FATES to deal appropriately with its biomass for (e.g.) a shrinking column.

[billsacks]

One other specific need occurred to me when I was making the changes for clm4_5_14_r214. This is relatively minor in the scheme of things, but I want to record it so it doesn't get lost:

In clm4_5_14_r214, I changed the timing of when landcover-related fluxes of biomass are added to the belowground pools. This involves various dwt_* fluxes in CLM, which capture the lost biomass when a patch shrinks. I moved this transfer to the belowground pools to earlier in the driver loop, so that this biomass will be handled properly by the dynamic landunits conservation code. This is important when there are changing column areas. I noticed some FATES-related code that may need to be moved in a similar way at some point.

Specifically, in src/biogeochem/CNCStateUpdate1Mod.F90, the trunk had this:

     ! plant to litter fluxes
     if (.not. use_ed) then    
     do j = 1,nlevdecomp
        do fc = 1,num_soilc
           c = filter_soilc(fc)
           ! phenology and dynamic land cover fluxes
           cf_soil%decomp_cpools_sourcesink_col(c,j,i_met_lit) = &
                ( cf_veg%phenology_c_to_litr_met_c_col(c,j) + cf_veg%dwt_frootc_to_litr_met_c_col(c,j) ) *dt
           cf_soil%decomp_cpools_sourcesink_col(c,j,i_cel_lit) = &
                ( cf_veg%phenology_c_to_litr_cel_c_col(c,j) + cf_veg%dwt_frootc_to_litr_cel_c_col(c,j) ) *dt
           cf_soil%decomp_cpools_sourcesink_col(c,j,i_lig_lit) = &
                ( cf_veg%phenology_c_to_litr_lig_c_col(c,j) + cf_veg%dwt_frootc_to_litr_lig_c_col(c,j) ) *dt
           cf_soil%decomp_cpools_sourcesink_col(c,j,i_cwd) = &
                ( cf_veg%dwt_livecrootc_to_cwdc_col(c,j) + cf_veg%dwt_deadcrootc_to_cwdc_col(c,j) ) *dt
        end do
     end do
     else  !use_ed
        ! here add all ed litterfall and CWD breakdown to litter fluxes
        do j = 1,nlevdecomp
           do fc = 1,num_soilc
              c = filter_soilc(fc)
              cf_soil%decomp_cpools_sourcesink_col(c,j,i_met_lit) = cf_soil%FATES_c_to_litr_lab_c_col(c,j) * dt
              cf_soil%decomp_cpools_sourcesink_col(c,j,i_cel_lit) = cf_soil%FATES_c_to_litr_cel_c_col(c,j) * dt
              cf_soil%decomp_cpools_sourcesink_col(c,j,i_lig_lit) = cf_soil%FATES_c_to_litr_lig_c_col(c,j) * dt
           end do
        end do
     endif

For the .not. use_ed piece, I have separated the updates due to phenology from those due to dwt_*, so that this block of code now looks like:

     ! plant to litter fluxes
     if (.not. use_ed) then    
     do j = 1,nlevdecomp
        do fc = 1,num_soilc
           c = filter_soilc(fc)
           ! phenology and dynamic land cover fluxes
           cf_soil%decomp_cpools_sourcesink_col(c,j,i_met_lit) = &
                cf_veg%phenology_c_to_litr_met_c_col(c,j) *dt
           cf_soil%decomp_cpools_sourcesink_col(c,j,i_cel_lit) = &
                cf_veg%phenology_c_to_litr_cel_c_col(c,j) *dt
           cf_soil%decomp_cpools_sourcesink_col(c,j,i_lig_lit) = &
                cf_veg%phenology_c_to_litr_lig_c_col(c,j) *dt

           ! NOTE(wjs, 2017-01-02) This used to be set to a non-zero value, but the
           ! terms have been moved to CStateUpdateDynPatch. I think this is zeroed every
           ! time step, but to be safe, I'm explicitly setting it to zero here.
           cf_soil%decomp_cpools_sourcesink_col(c,j,i_cwd) = 0._r8
        end do
     end do
     else  !use_ed
        ! here add all ed litterfall and CWD breakdown to litter fluxes
        do j = 1,nlevdecomp
           do fc = 1,num_soilc
              c = filter_soilc(fc)
              ! TODO(wjs, 2017-01-02) Should some portion or all of the following fluxes
              ! be moved to the updates in CStateUpdateDynPatch?
              cf_soil%decomp_cpools_sourcesink_col(c,j,i_met_lit) = cf_soil%FATES_c_to_litr_lab_c_col(c,j) * dt
              cf_soil%decomp_cpools_sourcesink_col(c,j,i_cel_lit) = cf_soil%FATES_c_to_litr_cel_c_col(c,j) * dt
              cf_soil%decomp_cpools_sourcesink_col(c,j,i_lig_lit) = cf_soil%FATES_c_to_litr_lig_c_col(c,j) * dt
           end do
        end do
     endif

with a new routine to handle the dwt_* terms, which is called earlier in the driver loop.

Specifically see the TODO note in the above snippet. My sense is that FATES_c_to_litr_lab_c_col (etc.) may combine fluxes from a few sources. In that case, perhaps this needs to be split into its different components for this to work right.

@rosiealice commented:

It's correct that the "FATES_c_to_litr_lab/cel/lig_c_col" fluxes are the sum of a couple of different processes, but the amalgamation of those currently happens inside of FATES. More critically, maybe, is that there is a separate set of CWD pools that feed into the soil decomposition and provide a buffer between the input (phenology, mortality) and the output (fragmented litter that goes into the decomposition process) which might change the logic of where these things need to be calculated, and might ultimately simplify it?

[rgknox]

Thanks for starting this thread @billsacks.
I am trying to think of examples of times that FATES needs to know the column size. So much of what happens inside FATES is area independent, so I can't think of any right now.
I think that the spatial averaging from history writes does not require knowledge of the column area or fraction on the FATES side.
We may have some fire code that has some code tied to the grid-cell, but I think that is going to be deprecated soon.

[ckoven]

thanks @billsacks for starting this. re the FATES_c_to_litr_lab/cel/lig_c_col, the main thing is that these fluxes are persistent between a daily FATES tilmestep on the upstream side and a half-hourly CLM timestep on the downstream side, so if the area of a column changes in the middle a day, there'll be balance issues...

[billsacks]

I am trying to think of examples of times that FATES needs to know the column size.

I agree that, in general, FATES should not need to know its column size. However, I think it will need to know when its column changes in area:

If its column increases in area, then presumably it will want to create a new 0-age cohort (or something like that...).

If its column decreases in area, then its aboveground biomass doesn't need to change on a per-area basis. However, I think CLM will need to know how much aboveground biomass was lost so that it can handle the fate of this lost biomass appropriately.

[rosiealice]

For fire, at present we need to know the size of the grid cell to convert from the size of the fires (which have real dimensions) back into the fraction of the grid cell that is burned. However, if the number of ignitions was per unit land area, rather than per gird cell, this problem would go away (and there's no reason that can't be the case).

…

On 9 January 2017 at 04:42, Bill Sacks ***@***.***> wrote: I am trying to think of examples of times that FATES needs to know the column size. I agree that, in general, FATES should *not* need to know its column size. However, I think it will need to know when its column changes in area: If its column increases in area, then presumably it will want to create a new 0-age cohort (or something like that...). If its column decreases in area, then its aboveground biomass doesn't need to change on a per-area basis. However, I think CLM will need to know how much aboveground biomass was lost so that it can handle the fate of this lost biomass appropriately. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#173 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMWsQ6U9Z-XctIwozkR7cvKRrkxiZuh-ks5rQh0PgaJpZM4LdNzm> .

-- ------------------------------------------------------------------------ Dr Rosie A. Fisher Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305 USA. +1 303-497-1706 http://www.cgd.ucar.edu/staff/rfisher/

[ckoven]

@billsacks it seems like the needed ability is for CLM to handle a transfer of area from a decreasing-area primary forest to an increasing-area secondary forest and at the same time having the ability to change some fraction--ranging from none to all, and possibly with some complex structure of size and/or pft--of the biomass into harvest pools, and keep the rest as live trees. so a possible sequence of events that would be needed would be for one column to be able to (1) take part of another column's area, (2) clone that donor column's patch/cohort structure (3) modify it in some way, and then (4) add it to the possibly-existing structure already present on the receiver column.

[billsacks]

@ckoven - Yes, that's part of it. But in addition to transitions between primary and secondary forest, there are also transitions between forest and crop, glacier, urban, etc. This is important because some of these transitions (glacier) will necessarily originate outside of FATES.

[ckoven]

@billsacks right, but those would seem to be simpler applications of the general case, combined with already existing capability from CLM? if a FATES column is becoming one of those non-FATES columns, you just harvest 100% of the biomass and keep the soil carbon, whereas if a non-FATES column is becoming a FATES column you just increase the FATES column area and make that all an increase of the the zero-aged patch area?

[billsacks]

@ckoven - Yes, good point. I wanted to make it clear that, somehow, the notion of "your column area changed" needs to be passed through the FATES API.

[ckoven]

@billsacks -- agreed, I guess my point is that that info also needs to be accompanied by an "it changed from this structure, and had that operation performed as part of the transfer". the first part of that would seem to require passing the fates site object itself through the API so that it can be cloned.

[billsacks]

@ckoven - I don't completely understand this - but I also don't think I need to completely understand this right now.

I'm thinking that, at some point, I should probably walk some of you through how this works without FATES.... But that can wait until someone on the FATES team actually has the time to work on this.

[ckoven]

@billsacks yeah, that'd be great.

[rgknox]

Some thoughts that seem relevant to this conversation:

As we all know, FATES kind-of bypasses the HLM to handle history IO that is a result of FATES processes. It happens by a hand-shake between FATES and the history IO buffer... stuff. So these FATES history variables are only for natural vegetation, as crops and other landunits can't contribute to these output variables. I think this is fine and dandy for this specific set of variables, but we should make sure this is clear in the history long-name field, and in the name field (using a FATES_ name).

On the other hand, there ARE history variables that I am sure the HLM wants to continue writing to the history buffer regardless of what vegetation model is turned on, using its own memory, spanning LUs and such. Like biomass or leaf area for instance. We need to have this list of the history fields that the HLMs want to track when FATES is on, so we can make the pass back. If we have that list of what the HLM expects to send to history, we can tell it what it needs to know.

[billsacks]

@rgknox : You raise a very good point, though I would suggest moving that to its own issue, since I think it's mostly orthogonal to this issue.

[billsacks]

Meeting notes: https://docs.google.com/document/d/10VIAXlh2MDlc9QFdCdtY_h2esXXwHHPjLCAeFYwXOWc/edit

[rosiealice]

Thanks for sending these round Bill. I've shuffled them around a little. Perhaps the latter part (on the wrap up discussion) is of greatest interest. We came up with a basic plan for minimalist implementation, based on the idea of having all land use at the patch level, with flags to keep the different categories from fusing. Latter implementations could potentially build on this to include, say, different columns, but this is probably the simplest way to get to something usable... Thanks for coming and for your contributions! -Rosie

…

On 27 February 2017 at 20:03, Bill Sacks ***@***.***> wrote: Meeting notes: https://docs.google.com/document/d/10VIAXlh2MDlc9QFdCdtY_ h2esXXwHHPjLCAeFYwXOWc/edit — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#173 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMWsQ7HXr1zUufLipJhfEX4_IaE2g2Zaks5rg45ugaJpZM4LdNzm> .

-- ------------------------------------------------------------------------ Dr Rosie A. Fisher Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305 USA. +1 303-497-1706 http://www.cgd.ucar.edu/staff/rfisher/

[glemieux]

Per issue triage see if we can find a more recent issue to cross post this to.