Drydep issue with FATES-NOCOMP in coupled model

[kjetilaas]

from @mvdebolskiy:

DryDepVelocity (which is always called when dry deposition is on) need Monthly LAI either from LAI-streams or from the surface dataset to determine the seasonal_index which is used in drydepvelocity parameterization. The LAI that is read from surface is actually LAI for a reference year 2005 and does not change at all. (check depvel_compute routine).

Since fates does not actually read any PFT data from CTSM, you will get a dimension mismatch error, since surface dataset has a 78/16 pft dimension length, while sets pft dimension to whatever.

[mvertens]

@kjetilaas - I have created a new discussion #78 that summarizes how drydep velocities are computed in CTSM. Hopefully this will provide some clarification.

[rosiealice]

In the meeting today we had a look at this code and determined that the dry dep needs to know from the vegetation model

1. The Wesely (1989) plant funcitonal type (currently hard-wired from the CLM PFT space in the code)
2. The season index, used to 'calculate' the surface resistance, thus used in the drydep routine.

A reasonable first step to fixing this is to create a wesely PFT index varialbe in the FATES parameter file, and send that to the dry dep code. This is a very similar approach to what we did in MEGAN and (compared to the alternative of going via the HLM PFT definition) is robust to changes in the HLM PFT definition that FATES cannot control. (n.b. the ELM will change to having more arctic shrub PFTs in the not too distant future. So we need the FATES parameter file to be somewhat independant of that).

So what I plan to do as a first step (before tckling the season index) is to make this PFT index.

But my question is which codebase should I base it off? The main FATES repo? The tag we are using in NorESM now from https://github.com/NorESMhub/CTSM/blob/noresm/Externals_CLM.cfg ?

Of course we will want to get this back into the FATES code in the not too distant future (before it becomes stale). So I don't want to start off in the wrong place. @mvertens @mvdebolskiy do you have any thoughts?

[mvdebolskiy]

You can start from sci.1.73.0_api.35.0.0 tag on NGEET/fates which is checked out by ctsm5.2.005-noresm_v3, the latest version of CTSM we have on NorESMHub right now.

[rosiealice]

OK great. I will do that. :)

[rosiealice]

Say for the sake of argument I had made some FATES code modification in a branch here:
https://github.com/rosiealice/fates/tree/drydeposition_sci.1.75.0_api.35.0.0

and these was based off of a tag: sci.1.75.0_api.35.0.0 (I used this one as it contains the vertical respiration scaling we need for the NOCOMP simulations, but does not change the API. NorESM currently points to sci.1.73.0_api.35.0.0)

And the changes relative to that tag were:
https://github.com/NGEET/fates/compare/sci.1.75.0_api.35.0.0...rosiealice:fates:drydeposition_sci.1.75.0_api.35.0.0?expand=1

Where should I make a pull request for this code? The current version of FATES on NorESMhub is a long way behind this tag... Should we updated it before I try and do a PR?

[rosiealice]

...similarly, should I start the modifications for the parallel CTSM side code from here? Or?

https://github.com/NorESMhub/CTSM/tree/noresm

[kjetilaas]

I would say we should update both, and make the PR to the NorESMhub versions of FATES and CTSM.

[mvertens]

I agree with @kjetilaas.

[mvdebolskiy]

I've made NorESMhub/noresm branch. You can make your pull request into that one. It's on the sci.1.75.0_api.35.0.0 tag right now

[rosiealice]

Brill. Thanks...

[rosiealice]

So the issue I discovered during the meeting was indeed the last edge-case I needed to deal with, and the code is now running in coupled NOCOMP mode.

Can someone make a 'noresm' branch on the NorESMhub/fates repo so I can push the changes there? @mvertens @mvdebolskiy

Ignore this branch that is already there
https://github.com/NGEET/fates/commits/drydeposition_sci.1.75.0_api.35.0.0/
this is not up to date.

[mvertens]

@rosiealice - there already is a noresm branch for the fates repo on noresmhub.
If you do the following in your code sandbox in the clm/src/fates directory:

> git remote add noresmhub https://github.com/NorESMhub/fates
> git fetch noresmhub
> git checkout noresm

You will see the following (if you use my git logg command)
$ git logg

*   6c85a1b0 (HEAD -> noresm, tag: sci.1.75.0_api.35.0.0, noresmhub/noresm) - (6 months ago) Merge pull request #1161 from jenniferholm/calibration_dayl-factor-switch - Ryan Knox
|\
| * a9b52307 - (6 months ago) reverting to parameter file from main, because daylength factor switch was already in there - Ryan Knox
| *   668fabd4 - (6 months ago) trivial merge resolution - Ryan Knox
| |\
| |/
|/|
* |   04afb122 (tag: sci.1.74.0_api.35.0.0) - (6 months ago) Merge pull request #1149 from JessicaNeedham/jfn-leafmr-vert-scaling - Ryan Knox

You want to do a PR to noresm in the noresmhub repository with your code. I'm happy to have a zoom chat early this afternoon if that would help.

[mvertens]

Best practice is that branches should not be 'pushed' changes back to noresmhub repositories. The suggested approach is to always do PRs that have at least one review. In our case this implies making PRs to the noresm fates branch in noresmhub.

[rosiealice]

Sorry, I meant pull of course :)

[rosiealice]

I had an email exchange with Maria val Martin whoworked on this code previously. She said:
" The dry deposition scheme in CLM5 (and many other models) is still based on the old, classic Weseley (1989) parameterization. In Weseley (1989), the seasonal indexes are used to represent changes in surface resistances (e.g., stomatal and cuticular resistances) due to vegetation activity, crop cycles, and seasonality. That is, they mean to capture biological processes (e.g., stomatal opening/closure, senescence, harvest, etc) rather than aerodynamic properties like the roughness length. As you said, this is simplistic and mainly works for temperate regions and is less applicable to tropical regions, for example.

In the original scheme, roughness length is a static parameter, set for different land use types. In CLM5, I believe this is handle in FrictionVelocity.F90 and uses the canopy height and a fixed ratio depending on pft (??).

Back in 2017 (!!), I attended an ozone dry deposition workshop that led to some publications, eg, Clifton et al. 2022, 2023
I couldn’t contribute to the articles as I couldn’t fit anything else on my plate at the time but followed their outcomes. These papers note that many models use the Weseley (1989) parameterization as a baseline, but their implementation often differs quite a bit from the original description. So, in my opinion, any adaptation you have made for FATES should be fine, especially since you are planning on doing some sensitivity analyses :)

I had a quick look at your code, and your approach seems reasonable to me. I like you consider a different definition for seasonal indexes for the NH and SH. I couldn’t find a definition for winter (i.e., drydep_season_pa(ifp) = 4) though. Apologies if I missed it!

Clifton et al. (2023) supplementary material may be helpful as it summarizes dry deposition parameterizations across different models and you may find some more process-based equations that you can apply in FATES. For example they propose a process-based equation for roughness length (Eq. 2) for their model intercomparison, based on canopy height and LAI. Updating some of dry deposition scheme for FATES may be a full time job though :)