Turn on use of ndep from CAM/datm and turn off (and remove) ndep capability inside of CTSM

[ekluzek]

datm is now always sending ndep to CTSM. We don't think CTSM is listening to it, and right now CAM

The CAM issue about this

https://github.com/ESCOMP/CAM/issues/104

A related CTSM issue:

1844

The closed CDEPS issue:

https://github.com/ESCOMP/CDEPS/issues/36

Definition of done:

• [x] Have both CAM and DATM always send ndep to CTSM
• [ ] Make sure ndep inside of CATM/DATM handle all the cases needed for CTSM
• [ ] Make sure results are similar for all configurations of CLM-BGC
• [ ] Remove the ndep reading and handling code inside of CTSM

[ekluzek]

As of cam6_3_098 CAM is now passing ndep through the coupler in all cases. So we should start working on bringing this change in.

[billsacks]

As of cam6_3_098 CAM is now passing ndep through the coupler in all cases. So we should start working on bringing this change in.

If I remember correctly from our discussion a few days ago, @ekluzek proposed a multi-step process that I agree with:

• First, change the logic so that CTSM is always getting ndep from atm (expect small changes)
• Then (in a following tag) remove now-dead code to read ndep in CTSM

[klindsay28]

I'm curious why the ability to read ndep from a file is being removed. I can imagine a scientific experiment with WACCM (or CAM-chem), that computes ndep prognostically, but wanting to run with different ndep forcing, say to examine the effect of prognostic ndep vs prescribed ndep in that configuration. Or if you wanted to support such an experiment, would you rely on WACCM reading a different ndep than it is prognostically computing and pass that to CTSM? Can it do that?

[billsacks]

Interesting point, @klindsay28 . Do you see that as being significantly more valuable or more likely for someone to want to do than prescribing other fields that typically come from the atmosphere? (I realize that what you're describing would be a useful general capability, not specific to ndep.)

My feeling is that, because we're already struggling under the current maintenance burden, we don't want to keep code around just because someone might theoretically want to use it, but if you feel it's likely that someone will want to do an experiment like this, then that would be good to know.

[ekluzek]

Note, that someone could experiment in this way with ndep forcing for a CAM or a CPLHIST case. What I think you probably couldn't do is to run fully CAM chemistry this way. But, I think doing a CPLHIST case might be a way to replicate doing even that kind of experiment. But, @billsacks question is a good one, is this something that is likely to be done? Has it been done with the current setup where it is easy to do? This is something we need to hear from scientists working in the Land-Atmosphere interaction space which is specialized in a way that we don't normally think about. It would be helpful to hear from people working in that space.

Practically it'll likely take us a bit before we fully remove ndep from CTSM, so people could likely still use the last version where this is available if needed.

[wwieder]

In the SE meeting today we agreed this should come in, but it's low priority at the moment (at least for CTSM science). @ekluzek said this should come in as its own answer changing tag. @olyson noted this will require testing to make sure the answer changing results are acceptable.

[wwieder]

This should receive a milestone, so we don't forget it.

[mvertens]

My concern about the current implementation is that having clm continue to read in ndep in non-WACCM configurations might lead to cases where the ocean and land read in different ndep forcings.

[mvertens]

Looking at the CTSM code in more detail I now realize that datm is not providing all the scenarios that CTSM needs. That said - CTSM should always receive ndep from cam when running wiht cam to be consistent with whatever the ocean is receiving. But I think this can be done on the CAM side.