Handling gross rather than net transitions for FATES

[billsacks]

Introduction

@ckoven asked me to give some thought to what would be needed for the dynamic column/landunit code to handle gross transitions - via a transition matrix - rather than the current handling of only net transitions. Also, relatedly, we talked about handling water and energy conservation more rigorously so that migration from one column to another would maintain the correct state variables.

I'm starting this discussion to note my initial thoughts on this, as well as to provide a place for further discussion of this future functionality. I have only given this a bit of thought so far, and it's been a long time since I've had my head deeply in the relevant code, so what I say in this initial comment should be taken with that in mind. (A few years ago I expressed a feeling that a change from net to gross transitions could be a lot of work, so I'm a little worried that I'm forgetting about some big piece that may be needed in my below analysis, where my conclusions don't feel quite so dire....)

See also

There is also a bit of relevant discussion in NGEET/fates#936

Two modules are especially relevant to this discussion:

• https://github.com/ESCOMP/CTSM/blob/master/src/dyn_subgrid/dynColumnStateUpdaterMod.F90
• https://github.com/ESCOMP/CTSM/blob/master/src/dyn_subgrid/dynSubgridDriverMod.F90

Handling gross transitions

A first important point – which I also mentioned in the discussion with @ckoven yesterday – is that, in non-FATES CTSM, we currently separate the patch-level/aboveground updates from the column-level/belowground updates. See this comment and the surrounding code:

CTSM/src/biogeochem/CNVegetationFacade.F90

Lines 772 to 779 in 4ca9e44

	! It is important to update column-level state variables based on the fluxes
	! generated by dyn_cnbal_patch (which handles the change in aboveground / patch-level
	! C/N due to shrinking patches), before calling dyn_cnbal_col (which handles the
	! change in belowground / column-level C/N due to changing column areas). This way,
	! any aboveground biomass which is sent to litter or soil due to shrinking patch
	! areas is accounted for by the column-level conservation. This is important if
	! column weights on the grid cell are changing at the same time as patch weights on
	! the grid cell (which will typically be the case when columns change in area).

To the extent that we can continue to do the same separation for FATES, I think that will make things easier. Here I'm focused on the column-level/belowground updates. I'm assuming that FATES will handle its own patch-level/aboveground C/N dynamics/conservation, though some work may still be needed to connect FATES's handling of this to CTSM.

The good news is that I think that a change from net to gross transitions could be encapsulated in dynColumnStateUpdaterMod without requiring extensive changes in multiple places. This module could be rewritten (if we only want to handle gross transitions moving forward), or an alternative version could be created (so we'd have a version that deals with gross transitions in addition to the current one that deals with net transitions). I think this entire module would need to be rewritten to handle gross transitions, since the logic there is fundamentally tied to dealing with net transitions, but that should be a manageable undertaking, and is a lot easier than needing to make changes throughout the code base.

The potentially more difficult effort in my mind is the work needed to fully specify the gross transition matrix. One piece of this is how to represent the transition matrix in a data structure that can be passed to the dynColumnStateUpdater. But the harder piece, I think, is how to handle column/landunit area changes outside of FATES: transitions to/from glacier (from CISM), lake (currently from a dataset, but eventually possibly from mizuRoute) and urban (from a dataset) areas, all of which can lead to growths or shrinkages of vegetated area. I think there are two options here:

(1) Come up with a way to specify a full transition matrix for all columns. This could be done with heuristic rules. In some cases, we could possibly get more information from the source than we currently do. For example, for changes in the glacier elevation classes, we could probably get more information than we currently do from CISM that would help inform this, though this could be challenging and my gut feeling is that this isn't worth the effort. Alternatively, we could use heuristic rules and ignore the possibility of getting all the information we can from the underlying source; this is probably easier (but may still be hard to completely specify), but would mean accepting that the transitions we come up with would almost certainly be inconsistent with what's actually happening (though arguably could be no worse than the current situation where we only deal with net fluxes, and in many cases could be better than that situation, at least if the heuristics were designed thoughtfully).

(2) Separately handle transitions within the vegetated landunit vs. other transitions. We could handle transitions within the vegetated landunit using gross transitions, while still handling other transitions using net transitions. This split would require more extensive changes to the dynamic landunit code: currently all column area changes are handled at once, so this would need to be split into a multi-step process. I haven't thought through what this would require in detail.

Handling conservation of water and energy states more rigorously

In my discussion with @ckoven yesterday, I said that I thought we could apply the CN-conserving infrastructure to at least some water state variables, at least for the case of transitions within the vegetated landunit, and could possibly apply this to temperature/energy variables (though that could be trickier because of a need to conserve energy, not temperature per se... one possibility would be to do an initial "conservation" of temperature followed by the current correction/fix to actually ensure energy conservation). My recollection at the time was that the main challenge in conserving water and energy states more rigorously was how to handle transitions between landunits, where the state variables differ more substantially.

However, I remembered another challenge: How to merge two snow packs. Snow packs in CTSM have a variable number of layers, with variable thickness of each layer, and each layer has both snow characteristics (e.g., density) and other state variables (e.g., dust). It is not at all clear to me how you would merge together two CTSM snow packs conceptually, let alone in code.

(There may be other challenging variables, too. I haven't thought about this carefully in a long time. See https://github.com/ESCOMP/CTSM/blob/master/src/biogeophys/TotalWaterAndHeatMod.F90 for all of the state variables that are important for conservation, which should give a start towards the variables important to handle. However, that still isn't a complete list, for example, excluding various snow properties that don't directly impact the snow pack's water and energy content.)

[ckoven]

Thanks @billsacks for starting this discussion. Glad to hear that your initial diagnosis is "not quite so dire"! The snow part is a really good point, will add that the list of things I need to think about.