Towards FATES w/ land use

[ckoven]

Edits. strikethrough-ing the text for things that we've done.

We've had a few meetings now to discuss how to get land use and land cover change fully integrated into FATES and working in both the E3SM and CESM systems. Our first meeting was at NCAR in March, 2017 (notes here: https://docs.google.com/document/d/10VIAXlh2MDlc9QFdCdtY_h2esXXwHHPjLCAeFYwXOWc ), with a second meeting at the E3SM PI meeting in Nov, 2018 and a third discussion organized by @jenniferholm at AGU last week (notes here: https://docs.google.com/document/d/1a6M6bOuNs263xkvcAoAk21BVxY74XFdutjib019jtnI ). It seems like there is now sufficient momentum and desire across projects to make this happen, so I'd propose this thread as a central discussion and organization forum to organize discussion around.

We've decided on a two stage process to get LULCC working in FATES:

1. The first step is to use harvest timeseries as a driver of land use, where harvest drives a logging module, which then leads to generation of secondary forest patches that all sit on the same FATES site and ELM/CLM column.
2. The second step is to integrate a full transition matrix with a more diverse set of LU/LC types. At this point, some goals are to have primary and secondary FATES lands sitting on separate columns, as well as (multiple) FATES columns coexisting with agriculture columns on the same gridcell. Here we could start to include more diverse land tiles like pasture, irrigated and/or fertilized plantation forests, etc. This is also where we will interface with the dynamic landunit infrastructure on both the CLM and ELM sides. [update: in process via #1040 ]

These steps correspond roughly to the center column and the right-hand-side column respectively of this diagram that I made after the March 2017 meeting:

For the purposes of sanity, let's restrict discussion on this thread to the things leading to step 1 above.

In the meeting at AGU, we identified several distinct pieces of development that need to happen. I'll try to list them here with some goals, milestones, and names of people possibly involved. Please correct me if I make any mistakes trying to summarize here. This is going to require fairly coordinated work by several people across institutions, so hopefully this thread can be a central place to discuss issues and progress as it arises.

1. Create a patch labelling system to separate primary and secondary lands, based on anthropogenic disturbance. For now, harvest is the only form of anthropogenic disturbance. Patches can only be fused with other patches of the same anthropogenic disturbance label. I volunteered to do this, and have a preliminary branch with this capability here: https://github.com/NGEET/fates/compare/master...ckoven:secondary_forest?w=1 Right now I am trying to test this and will issue a PR when I feel like I have something that works and makes sense. [update, PR in progress, #454]

2. Ensure that ELM is ingesting the LUH2 harvest data and interpreting it in a way that is capable of passing the info to FATES through the interface. @bishtgautam volunteered to lead this.

3. Create a land-use capability in the HLM/FATES interface so that both CLM and ELM can specify either a harvest wood volume or a harvest area, which FATES would then use to drive its land use dynamics. Also required is to then pass the harvest timeseries data through this interface on both the CLM and ELM sides. @rgknox has agreed to lead this effort. EDIT @sshu88 leading this

4. Diversify the logging logic, which currently is area-based and includes a set of parameters that are specified through the FATES parameter file (params here: https://github.com/NGEET/fates/blob/master/main/EDParamsMod.F90#L96 and default values here: https://github.com/NGEET/fates/blob/master/parameter_files/fates_params_default.cdl#L1023 ) so that (a) at least some of this info is passed via the land use interface so that it can be temporally- and geographically-varying rather than via the parameter file, and (b) we can alternately drive the model using harvest volume as a driver or the current area-based formulation. I believe that @huangmy @lawrencepj1 and @jkshuman all expressed some interest in this.

5. We didn't discuss this in the meeting, but I thing that I've subsequently noticed and thought about is the way we handle disturbance, which is that in any given day from any given patch, we only actually use the largest single driver of disturbance on that day. I.e. we either do fire or gapfall or land use depending on which is largest, not all of them simultaneously. The error from this shouldn't be too bad if we do all of our harvest on one day per year, but if we spread it out over the year this could become a serious issue. And it might give weird outcomes if we do all of our harvest on one day per year. So it might require reworking the disturbance model a bit to handle multiple parallel types of disturbance. Just want to point this out now as a possible thing that might be required. @jkshuman @rosiealice @rgknox and I have discussed this issue in the past; perhaps this application might be a reason to tackle it for real.

I'll cc all participants at last week's meeting here to make sure they are seeing this thread: @jenniferholm @ckoven @rgknox @rosiealice @dlawrenncar @kvcalvin @huangmy @bishtgautam @lawrencepj1 @jkshuman @bpbond @mpaiao. I'll also try to make a github "project" around this so we can track progress on this.

[ckoven]

staring at this some more. a couple other things:

• While we're modifying the interface, we probably ought to pass the harvest product as an output boundary condition to the CLM/ELM 1/10/100 year product pools, similarly to how we handle output litter fluxes. Currently it builds up in the currentSite%resources_management%trunk_product_site variable.
• I noticed that we had discussed point 5 in the above in potential disconnect between disturbance and litter fluxes #266

[bpbond]

Thanks, Charlie. It's great to have a central source for information and tracking purposes, and this thread is a great start.

either a harvest wood volume or a harvest area

Should C be added as an option here? If FATES offers a volume-driven entry point, would it then use internal wood densities for conversion to biomass and area?

[ckoven]

@bpbond yes, sorry, C mass is what I meant to say there, not volume.

[jenniferholm]

Hi @ckoven - thanks for starting this land use thread. This does a good job of summarizing our meetings, and glad that the larger FATES group can see these discussions and comment. I'll 'clean' up my notes document from our AGU meeting, as it still has some short-hand notes that I took during the meeting.

The 1 - 5 steps look great. I would really like to help on a one or two of these steps, and then some future steps as well.
@rgknox - could you and I divide and conquer step 3? It seems like this one is pretty large. We can discuss, since of course the interface touches in many parts between the HLM and FATES, but maybe I could work in the FATES side. So make sure the incoming harvest wood C mass or a harvest area drives the new land use change patches in FATES. Do you want to make a separate Issue for step 3?

I also see a need, and have an interest in step 5 and updating the disturbance model, so that it can handle multiple types of disturbances at the same time. This possible isn't as urgent as the other steps, but I can work on this. This does seem important when there are multiple smaller scale disturbances that when summed could add up to large areas being disturbance, but wouldn't have been previously accounted for.

Potentially getting ahead of myself --- but in the future, I'd be interest in helping to bring in additional LULCC types. Charlie's work of creating the new secondary forest patches will be great lead to follow for this. It seems like some sage advice from @lawrencepj1 would help when integrating a full transition matrix of LULCC types. Anyway, I'd be interested in helping with this, when we are in the expanding land uses second phase.

[ckoven]

@jenniferholm awesome, thanks.

[jkshuman]

Today there was a LULCC coordination discussion to bring together folks interested and actively working on this in both CLM and ELM.

Action items:

1. plan regular meetings,
2. update linked google doc with tasks that are active or should be active.

document with notes: https://docs.google.com/document/d/1ubiV1oW-8f0X47hj0aCkjT9NHJpuUmPQeKdjrahT2Xc/edit#

tagging meeting participants: @ckoven @rosiealice @rgknox @adrifoster @aldivi @dlawrenncar @jenniferholm @JessicaNeedham @lawrencepj1 @lmkueppers @wwieder @sshu88

[jkshuman]

Thanks @sshu88 I added you in there.

[glemieux]

Consolidating issues: see #173 for information

[ckoven]

Noting the discussion today on the CLM call to advance both (a) pasture representation and (b) land-use dynamics more generally. A key action item was to re-prioritize adding the capability to pass to FATES the LUH2 transition matrix data. Some current (as well as old) discussion on that point is at ESCOMP/CTSM#1077. Will be good to have a follow-up discussion soon with both CTSM and ELM stakeholders so that we can make that happen.

[ckoven]

Also just wanted to note here for reference the slides and agenda/discussion from the discussion earlier today in the CLM meeting call.