Implement moss and lichen in FATES

[huitang-earth]

As a part of the EMERALD project, we are now trying to implement moss and lichen in FATES.

After a review of existing literature on moss and lichen modelling, we decided to first focus on implementing biophyical processes of moss and lichen, i.e., optical properties, thermal insulation, water interception, photosynthesis in FATES.

We will first use sphagnum as a prototype for pamameterizing moss (e.g., https://gmd.copernicus.org/preprints/gmd-2019-51/gmd-2019-51.pdf) and Cladonia stellaris as a prototype for parameterizing lichen (e.g., https://www.duo.uio.no/handle/10852/64402 ). They are widely distributed in the Arctic region.

There is an issue whether to put moss and lichen as a vegetation layer or soil layer? Previous implementation of moss and lichen in LSMs, such as ORCHIDEE and JULES, put moss and lichen as a soil layer to better depict their thermal insulation effect. But we would like to treat moss and lichen as vegetation layer in FATES, which offers flexibility to add more detailed processes and vegetation dynamics related to moss and lichen in the future. But when describing heat transfer within moss and lichen layer, more soil-like functions may have to be used and additional parameters (e.g., thallus content) may be added into the equation. For this, we anticipate that there may be some code changes also in CTSM required.

We will appreciate very much for any thoughts or comments on the work. The issues and progress of our work will be posted and updated here regularly.

[jkshuman]

@huitang-earth thank you for moving the issue over here. Will be good to track progress and ideas. @adrifoster and I are talking about implementing moss for boreal-fire work in Canada. It will be good to share ideas.

[huitang-earth]

Copy comments from @ckoven in previous email exchange:

"I guess one aspect that may require some further detail is how to ensure that the soil insulation and porosity effects work as intended. Right now these effects are handled in a non-interactive way via Dave Lawrence's (who I’m adding to the cc list of this thread) organic soils parameterization (described in Lawrence and Slater 2008, https://link.springer.com/article/10.1007%2Fs00382-007-0278-1). In principle this could be coupled to make the concentration of organic material that is used to calculate the soil physical properties a prognostic variable. If a goal is to resolve these effects across disturbance gradients, the fact that soil physics is resolved at the column scale and disturbance at the patch will mean that the moss effects get smoothed across the column, so not sure how important that is — it probably depends a lot on the biome and is more important in the boreal where the fire disturbance cycle is coupled to the permafrost state than the tundra where that is somewhat less true. I’m also not sure how it would work from a water/energy conservation perspective when the soil porosity and heat capacity start to change with every update to the organic matter conservation. Lastly it may make sense to think about a spinup strategy sooner rather than later for this. When I tried to put some of these dynamics via a sort of simplified dynamic organic layer in ORCHIDEE (Koven et al 2009, https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2009GL040150) it was very very slow to converge because as the organic matter built up, the soils got colder and so the organic matter built up more, etc. In the proposed scheme here, because the organic insulation is coming from a living thing rather than soil carbon, the timescale of that growth should be shortened, so the effect on convergence should be mitigated, but given that permafrost is already very slow to spin up it may be worth thinking through a strategy (perhaps a maximum cap on the moss thickness for soil physical properties, so that if/when the system wants to turn into a deep peat that grows for thousands of years or longer, we don’t let it, or at least figure out how to get it to that alternative stable state more quickly)."

[rgknox]

@huitang-earth I'm starting to take a look at your changes, thanks for keeping us all in the loop as you do this work.

I also appreciate your objective to get the implementation broken up into manageable chunks if possible. I did a quick diff on your branch and master, and there are well of 10k additions and subtractions, but I noticed many of these changes are just whitespace changes. There are some tricks in github to remove whitespace changes from the diff, but for some reason it was not cooperating. Either way, as we move forward and start integrating your work in these phases, is there a way for you to get rid of these whitespace changes?

[huitang-earth]

@rgknox Thanks for your comments. I will try to work with @sunnivin to clean all the unnecessary white spaced and comments in the files.

Meanwhile, the 10K additions and subtractions (when you compare with "master" branch) is probably due to that I have merged @rosiealice's branch for FATES-SP mode into the branch. Because I want to use FATES-SP mode to do test runs. If you want to have a clearer picture what I have modified. You could check the following link, in which I compare the moss&lichen branch with the branch it was based on:
https://github.com/huitang-earth/fates/pull/1/files

If you prefer to seeing code developed from the "master" branch, I will be happy to add all the moss&lichen related changes based on the current "master" branch (without merging Rosie's FATES-SP code)

Another complication might be related to the parameter file. I create a new parameter file "fates_params_mosslichen_2.cdl" which have 12 default PFTs + moss + lichen, while in the original parameter file, I keep a lot of comments about how the parameters for moss and lichen should be changed. I am wondering if there are a good way to keep and share the information about how the values of each parameter files for moss and lichen are derived? I think it is important to keep these information. But I have not had a efficient way to keep them.

[rgknox]

Thanks for clearing that up @huitang-earth ! Much easier to see where your changes are now.

I see no issues with your changes to the default file, I like how you added entries for moss and lichen. The current default file, as I see it, is more of a place to hold all of the basic critical plant guilds (subject to interpretation) with some best-we-can-do values with no expectation of defsensible results, rather than a specific pft set that serves some scientific mission. Maybe at some point in the future we can maintain a PFT set that were used for MIPs that we don't want to mess with.

My only comment would be to finish some of the long-name descriptions like the stomatal_model type, for instance explicitly state what option 3 and 4 are. (although we may run into line length issues at some point?)

[rgknox]

I have to think and check on this more, but I don't think we actually read in the long-name info into FATES-CTSM (or FATES-ELM), so that string limit should only be limited by the NETCDF machinery (but I would guess it would hold pretty long strings?)

[huitang-earth]

Thanks for clearing that up @huitang-earth ! Much easier to see where your changes are now.

I see no issues with your changes to the default file, I like how you added entries for moss and lichen. The current default file, as I see it, is more of a place to hold all of the basic critical plant guilds (subject to interpretation) with some best-we-can-do values with no expectation of defsensible results, rather than a specific pft set that serves some scientific mission. Maybe at some point in the future we can maintain a PFT set that were used for MIPs that we don't want to mess with.

My only comment would be to finish some of the long-name descriptions like the stomatal_model type, for instance explicitly state what option 3 and 4 are. (although we may run into line length issues at some point?)

Thanks @rgknox . I will do this. Currently, "stomatal_model" 3 and 4 are used to denote moss and lichen, respectively. But in fact, they should have the same "stomatal model" type (i.e., no stomatal control). I have not figured out how to differentiate lichen from moss in the parameter file. Perhaps, we could use "fates_woody" or a new name "fates_lifeform" to denote different life form of plants (https://en.wikipedia.org/wiki/Plant_life-form)? For instance, 1=woody, 2=herbecious, 3=bryophyte, 4=lichen, ......etc....

[ckoven]

Hi @huitang-earth We are going through old issues and wanted to check in on the status of this effort. Are you still working on it, or is there any prototype code?