Plans for coupling FATES with dynamic land-units and columns

[rgknox]

Background: The land-models that drive FATES, are concerned with more than just natural vegetation. Therefore, we need enable FATES to interact with the land-models, such that it does the appropriate thing when the land-model dictates that there is no space for natural vegetation, some space for natural vegetation, or that this status has changed.

Here are some of my thoughts on this:
https://docs.google.com/presentation/d/1nXpdWxlzIK31XEC0zQAs2MPi175ttXr0gpj-g3kJjI8/edit?usp=sharing

[glemieux]

Thanks for collecting this all into one document; it makes more sense to me know. A couple of questions:

1. Am I understanding correctly that the statement below (page 8) is meant to preserve mass balance?

seed mass fluxes are routed to other columns as litter

2. This statement got me thinking: how do we envision handling land use transition depending on displacement type (in an ideal sense, not necessarily a near-term practical sense)?

Consolidate all biomass into FATES litter pools on 1 patch

[rgknox]

@glemieux , Re 1: exactly, we don't have cross gridcell seed dispersal, but when we do, we need to make sure that seed mass does make its way to all columns in the correct proportions (not just FATES)

Re 2: I've been thinking about this too. The more I think of it, if a FATES site becomes decactivated, it is because it does not represent any fraction of the land. At that point, there is no point to maintaining any biomass pools. (we do need to hold a token patch that holds all the area, just so the land model's weighting system has something to count) The reason for this, is that when we reactivate the patch (due to various potential reasons), we will be re-initializing the litter biomass in that site based on whatever column is now donating area to it. So there is no need to remember anything in FATES during deactivation.

[glemieux]

At that point, there is no point to maintaining any biomass pools.

Hmmm, I may need to chat face to face about this sometime. Am I misunderstanding the patch you mention in slide 8? I assumed it is basically a placeholder for some fraction of the original forest biomass that is "locked up" in a litter pool that can't be accessed (maybe because it hasn't been transported off site). This is what originally got me thinking since the biomass on the deactivated site in real-world terms may actually be there, but depending on the transition type the state of the litter might change over time. For example, an urban development may displace a large fraction of the biomass as litter somewhere else, but land flooded for a dam might just bury it.

[billsacks]

we need enable FATES to interact with the land-models, such that it does the appropriate thing when the land-model dictates that there is no space for natural vegetation, some space for natural vegetation, or that this status has changed.

I'm replying to this 2-year-old issue simply because it caught my eye when skimming through https://github.com/NGEET/fates/projects/2 .

In CTSM (and maybe ELM unless they have changed the original dynamic landunit implementation in this respect), it is important to distinguish between two things that are related but separate: (1) what is the current area of the natural vegetation landunit?; (2) is the natural vegetation landunit active?

Currently in CTSM, we always treat the natural vegetated landunit as active, even if it currently has 0 area. This has a few implications:

• You should not have any code that decides whether or not it should be run based on whether the area is zero or non-zero
• Code should be written so that all answers are the same, on a per-m2 basis, regardless of the area of the vegetated landunit – even if that area is zero! i.e., a "virtual" vegetated landunit should behave in exactly the same way as one with non-zero area
• One thing needed to achieve the above is that all sub-landunit areas need to sum to 100% area on the landunit, even if the landunit has 0 area. This means that you may need to make some arbitrary decisions about the composition of this virtual vegetated landunit
• On the plus side, you currently don't need to worry about how to initialize a previously non-existent vegetated (i.e., FATES-owned) landunit, although it's possible we'd want that flexibility in the (distant?) future.

The reasons for this current operation are:

• The virtual vegetated landunit provides spun-up conditions that allow us to initialize its water & energy state when it grows to non-zero area. (We also use the vegetated landunit as a close-enough approximation for the initial state of new crop columns.)
• In practice, the main areas (at least in a typical climate model resolution) where we have vegetated landunits with zero area are over the ice sheets. But we need to run the vegetated landunit over the ice sheets anyway in order to provide the forcings that the ice sheet model may need.

The tl;dr is: although we might change this in the future, currently you don't need to worry about activation / deactivation of a FATES-owned landunit, at least in CTSM. However, you do need to be able to gracefully handle a zero-area FATES-owned landunit equivalently to a non-zero-area landunit.

[ckoven]

just noting some recent discussion on this topic is in #936.

[mvdebolskiy]

ESCOMP/CTSM#309

This might be of interest.

[glemieux]

I'm using this OSF.io project to organize some of the materials (mostly google documents) associated with this project: https://osf.io/kwaf2/