CAM SCM use of CTSM restarts and spun up initial conditions

[jtruesdal]

I have a solution that allows the single-column model to use CTSM restart/initial data. Up until now, the CAM single-column model was only able to use a cold start initial land condition which severely biases the surface fluxes and atmospheric column over land points.

Currently, there is single column specific code in the CLM io routines that automatically limits the domain read from a netcdf boundary file to a single gridcell. The initialization routines that interpolate an initial condition to the current model grid are written to expect a global domain. The solution that allows proper initialization from and finidat file during single column mode is to selectively turn off the single gridcell read during the parts of the initialization that require a global domain of input data to do interpolation. It shouldn't be too hard to come up with a set of changes that will work for standalone CLM to allow it to run in single column without the need for creating a standalone single column initial condition. Like the SCAM version is should be able to simulate any land gridcell on the fly given a standard spun up global initial condition.

I would like to get some feedback on how best to port these changes into CTSM. They are incredibly useful for single column CAM using CLM and have been requested for years. They have also been requested by the AMP scientists working on the CLASP project. In addition to porting advice, I would like to run these changes against a set of regression tests to make sure they are bit-for-bit in standard CLM configurations. They are currently configured for clm5.0.30. I'm assuming Erik might be the appropriate SE to take a look at these. You can see the first cut at the mods by comparing my branch to clm5.0.30. release-clm5.0.30...jtruesdal:release-clm5.0.30.scm_clminit213

[billsacks]

Thank you very much for this @jtruesdal !!!

We quickly glanced through the code. One initial thought we had was to keep the flag as just 'read' or 'write', but add a new optional logical flag like 'global_even_in_single_column_run' (or a slightly shortened version of that, but something that makes it clear what it's doing).

Tentatively, @ekluzek will work with you on this as soon as he clears some other things off his plate.

[jtruesdal]

Thanks you two. I appreciate your look and think the suggestion is a good one. This go around my coding was a little rough, just wanted to see if you were amenable to adding this to CTSM. I'm will go though it more thoroughly with Erik for the PR. I know everyone is very busy right now and I am happy to follow up on Erik's timeline.

[mvertens]

I think it's important to make sure this also gets into the nuopc cap - since this is being used for NEON and is where I would like to see future single column work default to sooner rather than later if possible.

…

On Thu, May 6, 2021 at 11:51 AM jtruesdal ***@***.***> wrote: Thanks you two. I appreciate your look and think the suggestion is a good one. This go around my coding was a little rough, just wanted to see if you were amenable to adding this to CTSM. I'm will go though it more thoroughly with Erik for the PR. I know everyone is very busy right now and I am happy to follow up on Erik's timeline. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4XCE7V4SKQSVEOUSYE52DTMLJJ5ANCNFSM4326DIDA> .

-- Mariana Vertenstein CESM Software Engineering Group Head National Center for Atmospheric Research Boulder, Colorado Office 303-497-1349 Email: ***@***.***

[ekluzek]

@mvertens that's a good point. We do have a NUOPC SCM test that's part of our test list. And actually for this PR, I don't think there's any changes that need to go on in the cap for nuopc. So I think this is "nuopc ready". When this becomes a PR we should make sure the SCM tests run with initial conditions rather than doing a cold start, but that should be triggered for both MCT and NUOPC.

@jtruesdal the other thing we noticed is that your changes were based off of the clm5_0 release branch, so they should be moved to the latest development version on master. I think mostly your changes should slide in easily, but there are a ton of changes between the release branch and master so there might be unexpected issues doing that.

[billsacks]

there are a ton of changes between the release branch and master so there might be unexpected issues doing that.

and in fact there are some significant changes to ncdio_pio since the release branch.

[jtruesdal]

Thanks for the heads up. I'll get started on bringing this up to date, testing in prep for the PR and I'lll be ready when Erik has time. There is a regression test where we run CAM and SCAM and show that the SCAM column is BFB identical to its match in the global CAM run. I'm hoping to modify that test to include an initial condition land start and validate the SCM changes that way.

[jtruesdal]

@ekluzek We are committing updates to SCAM and I would like to be able to reference a land tag with the the single column land mods included. I've brought the code up to ctsm5.1.dev142. Here are the changes
https://github.com/ESCOMP/CTSM/compare/master..jtruesdal:ctsm:ctsm5.1.dev142_scamdev?expand=1
This code passes a bfb test with the new SCAM code giving bit for bit single column results when compared with a full 3d run using land with a warm start. Should I put a PR in to give you a chance to look at the changes more closely?

[ekluzek]

Hey @jtruesdal thanks for putting those changes together. This is something that would be really good to get in.

I looked at the diff you give above and it appears to have some other change along master besides your changes, from what I see. So yeah it would be easier to see what you've done by putting a PR in place.

We like to have PR's come in fairly early, just so we can start to see what they look like and so we can start planning on when they come in. By putting it in early we can do a code review that you can respond to, rather than later when there really isn't a chance to do that. If we have bigger changes or design level changes that we'd like to see we can get you working on those as soon as possible which is the best for everyone. When someone feels their work is totally complete and we ask for changes it feels pretty crappy to them, but early in the process it feels more collaborative and better for all.

So yes, please put a PR in, and we'll start looking at it and planning for it.

[jtruesdal]

Thanks for helping with this @ekluzek !

The PR is #2333. I think our PR process for my SCAM updates will take about 2 weeks for the atmosphere. It would be nice to include this as an external update to our CAM PR. If that timing is too short we can push ahead without it (keep the current cold start option) and make a separate PR when it's available in a CTSM tag. Regardless this has been in the queue for years and I'm glad we are finally able to make this happen. Thanks again for your help!