Split natural vegetation columns into LUH categories: primary/secondary forest, non-forest, pasture, and rangeland?

[ekluzek]

This is a design idea from @lawrencepj1 for how to handle managed pasture for both CTSM-FATES and CTSM-BGC. Currently we put all natural vegetation on the same naturally vegetated column. Another way to handle this would be to have columns for the LUH categories: primary/secondary forest, non-forest, pasture and rangeland. Each of those columns would then have a specific mix of PFT's that goes with that category. The full matrix of transfer rates between the categories would be read in from the landuse timeseries files. So the host land model (HLM) (CTSM in this case) would manage the transfer between the categories, and in the case of FATES, FATES would just manage the specific PFT mix on the column from the HLM. The HLM could let FATES know what category of column it is, and FATES could use that information in whatever way it needs. Since the HLM is managing the columns, FATES wouldn't need to know anything about the transfer matrix between categories that would all be managed within the HLM. And this design works for both running with FATES and with CTSM-BGC.

@lawrencepj1 can you expound on this starting point as you see fit? And feel free to correct anything I have here...

@ckoven

[lawrencepj1]

Thanks @ekluzek

Yes this is a great summary of the suggested FATES / CTSM discussion we had last week. This would also be represented in the CTSM big leaf model with the current BGC and Crop models. The one additional element to add would be that when changes in the LUH2 columns occur with FATES active the wood harvest and changes in above ground carbon would be calculated by FATES in which ever configuration was selected with the resulting fluxes returned to the HLM.

Peter

[billsacks]

There are definitely some appealing aspects of this suggestion. It seems like some key points are:

(1) Splitting the natural vegetated landunit into multiple columns at the level of the LUH categories. There is certainly an appeal to this from the perspective of realism. It seems like we have already tentatively decided to introduce new columns for pasture and rangeland, so I think this proposal includes one additional split: separating primary/secondary forest from non-forest (or are you also suggesting separating primary vs. secondary forest?). I guess some thought would need to be given to how this would interact with @swensosc 's hillslope hydrology? At first I thought that we should try to decide whether we want to do this before trying to make other decisions about the FATES-LULCC implementation, but actually it seems like we can do the broader design without knowing exactly how we want to handle this: I think we can agree at this point that we want to have > 1 column on the vegetated landunit (we have at least talked about having a separate column for pasture), and once we allow for that possibility, I'm not sure it's going to matter hugely if we have 2 columns, 4 columns or 100 columns. (I hope it's not 100. At that point CTSM may become slower than the atmosphere!)

(2) Having CTSM implement the area changes from the transition matrix rather than relying on FATES to do this. I don't understand FATES's needs well enough to know if this plan really gives FATES everything it needs – and the reverse, whether this plan would miss out on some extra information that FATES could provide back to CTSM if FATES were the one to dictate the final changes in column areas. Basically, as I understand it, the plan laid out above involves having CTSM adjust its column areas directly from the LUH data rather than (my previous understanding) feeding the LUH transition matrix to FATES and then having FATES dictate changes in column areas to CTSM. The above plan does seem simpler in this respect, as long as we're not losing anything major by doing this. (I suppose it would be possible to do a hybrid solution, where we have CTSM adjust its column areas directly from the LUH data but then still feed the full transition matrix to FATES if that would be useful.)

I'd like to hear @ckoven 's thoughts on this. Also, @ckoven , given that you may not be able to make the Feb 9 meeting, I'm wondering if we should have a pre-meeting to discuss some of this with you... I guess it depends on how much needs to be worked out for which you can provide unique perspective....

[wwieder]

I wondered if there are ideas / documents from last week's meeting that should be shared in this thread (or one in FATES)? @billsacks, @jkshuman , @adrifoster , @glemieux , @rgknox

[jkshuman]

@wwieder yes. we developed a design document based on the format created a while back by @adrifoster. (template is here https://github.com/ESCOMP/CTSM/blob/master/doc/design/design_doc_template.md) I am compiling notes and will share once those are cleaned up a bit. I am not sure it will go into this particular discussion, but it will find a home.