Adding an additional "moss/lichen" layer on top of the soil in soil temperature scheme

[huitang-earth]

We are exploring the possibility of adding an "moss/lichen" layer on top of the soil but below snow and surface water layer for the heat and temperature calculations of moss and lichen ( in "SoilTemperatureMod.F90"). It will be great to learn from the community how this could be done properly.

Following the current implement of soil-snow temperature scheme in "SoilTemperatureMod.F90", the "bmatrix" with addition (moss and lichen) layer may look like this:

As to the indexing of soil-moss-snow layers, one idea would be to create a new index variable for Non-Vascular plant:

NV=1 # if a column have moss or lichen
NV=0 # if a column does not have moss or lichen

The snow layer index will be like this:
j=snl+1-NV # top snow layer

If there is a moss or lichen layer in the column, all the snow layers' index will be shifted with -1.
If there is no moss or lichen layer in the column, the snow layer index will be the same as before.
Soil layer index remain unchanged in both cases.

Any comments or suggestions on this issue will be highly appreciated!

People involved: @kjetilaas, @sunnivin
This issue is linked to #1291 and NGEET/fates#707

[ekluzek]

A concern I have for this being able to be implemented is this issue #21 where we are concerned that you can't reorder PFT indices because of hard-coded assumptions in the code. That is if this becomes an additional index in the PFT parameter list, which isn't completely clear right now.

[huitang-earth]

Thanks @ekluzek for the comments. If we are using FATES, the PFTs can be freely defined and numbered. It will not be an issue. For CLM, we have been thinking to have a moss&lichen type rather than using PFT indexes to keep all the relevant variables and functions. Hope this will avoid the hard-coded PFT index issue. It seems to be unlikely to implement moss and lichen as a PFT in the model. :)

[ekluzek]

@huitang-earth pointed us to several documents on his design:

Code planning:

https://docs.google.com/document/d/1EzMCZLwmudNXEDCuUUXlCc2BTTIDf8ggCV-PzupDgz8

Flow chart:

https://docs.google.com/drawings/d/19dYZt8Y9885I5mZ9IeYxtRc7ssvCD132QiUEqr1RK-E

Schematic diagram:

https://docs.google.com/presentation/d/1Yz6n9l-tfv-_WeZj3gAXgW_i2KGutp2o

[ekluzek]

I feel like this is a pretty big reworking of the current model (although I could be wrong). But, as such it would be good to make its implementation done in smaller steps. And potentially simple changes tested first in a throw away version to see the impact. I do assume that you are embarking on this because you've evaluated that adding moss/lichen is scientifically important, but there might be details of adding it that could allow for simplifications. For example, is the radiative transfer through the moss/lichen layer critically important to have? Or maybe in certain conditions it is important and not in others (snow covered)? Another example is light showing through snow on the moss/lichen layer which we talked about some. The model currently doesn't allow it, could you do some testing to find out if that's an important effect or not? I'm throwing those two out as examples of what to think about. You may already have examined both of those in detail, I just want to encourage you to do that as much as you can whenever you have to do something different than how things are currently implemented in the model. In some cases you'll have to handle it differently which is fine, but if you can simplify your work by making the same assumptions already made that will make it easier/faster to get this into the model.

[ekluzek]

Another principle I want to endorse is an idea that @billsacks presented at one of the LMWG meetings: "Refactor before you implement your changes". The idea is that when you find the code makes it hard to do what you want to do -- you do some bit-for-bit refactoring to make it easier (or even possible) to do. And then you do the actual work of implementing what you want. But, at that point it's easy to do, because of the refactoring that you did that paved the way for what you really want to add. That keeps the code easier to work with, more extensible, and more robust, while also implementing your new capability. I think it also can make debugging the end result easier because you prepped the code to begin with. But, you can also get part of your implementation (the refactoring part) into the code base sooner this way -- so it's less likely for someone to break it with a future update. In a project like this there might be more than one refactoring that you might end up doing. But, I want to highly recommend this type of process.

[wwieder]

Is there anyone still working on this issue, or should it be closed for now?

[kjetilaas]

@huitang-earth should probably answer this himself, but my understanding is that the moss implementation is still work in progress, but the idea of adding an additional soil layer has been abandoned for now. So I think this can be closed (with the ongoing work covered by #1291 and NGEET/fates#707).

[huitang-earth]

@wwieder Thanks for bringing this up. As @kjetilaas said, we have given up the idea of adding additional moss/lichen soil layer for our current moss implementation due to technical difficulties. For the time being, this issue can be closed

[wwieder]

closing, this for now.