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.

[ekluzek]

This is a nice usability/documentation/remove-confusion type thing that would be good to get in before the release. But, it's not absolutely critical either. And when we switch over we need to do enough testing to ensure we aren't screwing something up in CTSM compsets for I compsets. So adding next here.

[ekluzek]

I'm pretty sure we are viewing this as a thing OK to complete after ctsm6.0.0, so I moved the milestone. But, still leaving the next.

[wwieder]

I agree, this isn't mission critical for the release, but it needs better documentation, as I'm still confused by where CLM is getting NDEP information (or where I could modify these inputs). Is moving this to a CLM6.1 milestone being done to triage the the 'must-dos' that have to be completed for a CESM3 release?

[ekluzek]

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.

Thanks so much @mvertens for noticing this and putting this comment in an issue. I while back I thought this wasn't a problem, but I tracked this down and it IS a problem all of the time. As implemented now, coupled cases won't send ndep over even in a WACCM configuration. I created an issue for it in CAM here:

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

There's also a good point here that ocean and land could have different ndep forcings until this issue is resolved. It's going to at least be different by a small amount because of the different mechanisms. But, if there is a bug in ndep for land or ocean (or they aren't updated in unison), they could be way off. So that's a really good observation.

[ekluzek]

I need to reach out to CAM people about making sure this is right when coupled to CAM and WACCM is running so it's provided.