dry-deposition work with FATES for normal FATES competitive mode

[ekluzek]

Currently dry-deposition (which is needed when coupled to CAM-Chem) only works for CN or BGC mode. We need this to work when running with FATES as well.

From our discussion on CTSM-FATES this is something we'd need in the CTSM-FATES v0 version which also needs to run with F compsets. We want to get F2000 and FAMIP compsets to work with FATES.

Definition of done: FATES is able to run and produce dry-deposition coupled to CAM in normal FATES competitive mode

[ckoven]

Hi @ekluzek @billsacks was just looking over your V1 CTSM-FATES list and saw this. Does this require anything on the FATES side, or is it just in the handling of things on the CTSM side?

[ekluzek]

@ckoven yes I don't think anything is required on the FATES side for this. Looking over the code I think the main thing is we need to try running drydep with FATES. We've never done that before hence I suspect it won't work. But, in looking over the code I think it might actually work. One of the issues is that FATES runs with the logical use_cn False, and the drydep behavior depends on use_cn. So I'm not sure if that will work right when FATES is being used. In this context it might need to be a use_cn==T .or use_fates==T kind of thing. This is one of the places where use_cn is a confusing control variable.

[ekluzek]

I looked at this again in context of making sure we don't break this any worse than it is now. We should be able to call DryDepVelocity for FATES if we provide: elai, fsun, rssun, rssha from FATES which technically is already done. There are also some canopy flux variables that are input, that should be fine for FATES.

drydep Initializition is already being done and it's called at run time as well even for FATES. If there are any FATES variables that do need to be provided before drydeposition is called a prep_drydeposition call could be added that would be something like this...

      if (use_fates) then
         call clm_fates%prep_drydepositionfluxes(nc, fn, filterp, photosyns_inst...)
      end if

fsun gets added from FATES in wrap_sunfrac, and elai in wrap_update_hlmfates_dyn. rssun and rssha is in wrap_photosynthesis. So these are all done after FATES is run, so I don't think that even the above needs to be done -- unless it's important to get the value before rather than having the values lagged by a time-step.

What we do need to make sure we preserve is that DryDep currently still requires annual LAI to be read in, so we need to keep that even when running FATES.

[ekluzek]

Since, it looks like there is a chance this will work pretty much as is. We should add a new test to the test list for both the aux_clm and fates test lists to turn drydep on with FATES.

[rgknox]

@ekluzek I don't have a good sense of how the dry-dep scheme works, but I'm keeping my eye on this issue. @ekluzek, I and others may team up and look at this together at some point. My original concern was that drydep is somehow dependant on pft/patch scale information which is conceptually inconsistent with FATES, but it looks like maybe that is not true, so good!

[ekluzek]

@rgknox no you were right. Everything is based on the PFT type "ivt" array, which as we have been discussing makes no sense for most FATES patches. We should make sure it's set to something that indicates it's a FATES patch and doesn't indicate a veg-type. Maybe it should be negative so it will trigger a subscript out of bounds if it's used?

I think this means that we should be able to get this to work for FATES-SP, but it will be a problem for general FATES. FATES will need to do something like tell CTSM how many different PFT's are in a patch and the dry-deposition mechanism will need to operate over them.

[ekluzek]

I'm going to spinoff a separate issue for dry deposition to work with FATES-SP mode. We actually are close to having that at least function. #1766 will get it working. We'll need to do some work to make sure it's working correctly, but it does function.

[ekluzek]

For this to work in general for FATES I need to have an interface in FATES that returns a list of PFTs and their area. I'm not sure how to handle the fact that areas overlap in FATES. But I'll start an issue on the FATES side and we can discuss there.

[ekluzek]

The issue for FATES-SP mode is #1784. The issue in FATES is:

NGEET/fates#879

@rgknox and I met and decided that we should make sure dry-deposition is currently disabled with regular FATES, since the arrays won't even be dimensioned correctly. I've added something that aborts with a warning in build-namelist if you try to turn on FATES and drydep. I'll also expand that to the FORTRAN code. I'm also going to add some comments to the code that talk about what needs to be done to get it to work with dry-deposition for FATES

[ekluzek]

I'm closing this as a wontfix for now, as we have this working for FATES-SP and we will get this working for no-competition mode. Later more scientific research will be done to figure out the best way to handle this.