Updating CTSM science components in CESM3 development

[wwieder]

It looks like the 26c case is still pointing to a CLM50-BGCcrop case. I wonder if we can transition to CTSM5.1 physics (the latest CTSM5.1 dev tag) so that we can start testing out updates we've made to the land model since CESM2?

Along with this we're also testing out CTSM5.2, which includes updates to surface datasets. I'm not sure at what stage these should come into coupled model simulations, but wanted to bring up this topic too.

[adamrher]

can you edit the title so it refers to CLM science updates?

[wwieder]

Currently 5.2 is a branch tag, but just pulling from the latest main CTSM5.1dev code would be great.

I'm a little fuzzy on the complications of bringing in CTSM externals for F-cases, or the I-case runs you're wanting to run (presumably to get better initial snow conditions using CPL_HIST output)? In general, I'd encourage use the the latest CTSM development branch, however, because that helps us evaluate the land model in configurations that we may not regularly test. @billsacks and @ekluzek do you have other thoughts on this?

Incidentally, Adam, we have an open PR that updates snow physics in SNICAR, that would also be helpful to get evaluated in coupled runs once it's merged into a CTSMdev tag, but this is a little bit off...

[adamrher]

I would say that if you are interested in evaluating the land model in 10-20 year long F-cases, then we can make a point to bring in the current head of CTSMdev to the code base we are using for the next phase of experiments (see here: #193). I'm thinking of pushing the I-case for generating new inic (yes, forced by CPLHIST) off until we have the new surfdats (we have an acceptable CTSM inic for 26c that will use in the meantime). At that time, I'd also be happy to take a look at SNICAR mods. But I envision this all occurring after this F-case phase where we tune up the clouds. Perhaps there is a way to do this in parallel as to not wait around for the clouds (e.g., using 26c) but that might be risky as we bring in and tune up the new PUMAS and CLUBB externals and change the clouds.

[billsacks]

Thanks, @wwieder and @adamrher for starting this discussion. It's important to distinguish here between the CTSM tag you're using vs. the CTSM physics version you're using. The latest CAM development branch is already using a version of the CTSM external that is close to the latest (ctsm5.1.dev103; we're about to make dev113, but 103 isn't far off from that, and I assume CAM will update to the latest once the next CESM beta tag is made, which should be in a couple of weeks; CESM should also be pointing to the latest CTSM tag at that point as well). However, out-of-the-box F and B compsets are still using the older CLM50 physics even with these newer CTSM tags. So updating to CTSM5.1 physics is a matter of changing the compset (by using CLM51 in the compset long name rather than CLM50) but not necessarily the tag. (However, note that you may also have to tweak LND_TUNING_MODE; we're having some discussion on this in an email thread.)

To make things a bit more complicated, the update to CTSM5.2 will likely require an update in the CTSM tag (to a not-yet-made development tag), but not the compset: we don't plan to have a separate CLM52 physics option because the differences between CTSM5.2 and CTSM5.1 – which involve just changes in the surface datasets – are going to be done in a non-backwards-compatible way. (@adamrher these changes will include bringing in the new glacier data that you were involved with, among other things.)

[adamrher]

Thanks for clarifying, Bill. This simplifies things that the head of the CAM trunk already has fairly up to date CTSM externals ... and we can run 5.1 physics right now. The wrinkle is (of course) that the head of the CAM trunk is ahead of our coupled simulations (for example we can't run 26c with the latest tag because CLUBB and PUMAS externals have been updated), but the CTSM externals for these coupled simulations are not so old either; ctsm5.1.dev082.

So we can easily turn on 5.1 physics for the F-case cloud tuning phase we're about to enter, if that's of interest to Will et al.

[wwieder]

Yes, thanks for clarifying Bill. And yes, Adam, turning on CTSM5.1 physics seems valuable to me, as I'd rather discover potential issues sooner in our development cycle than later.