Should we continue supporting CLM4.5 after the CLM6 release?

[wwieder]

With the release of CLM5 we stopped supporting CLM4. Current CTSM development tags support CLM4.5, 5.0, and 5.1 physics options.

Deprecating old physics configurations saves maintenance costs for old versions of the model that are not used much by the community.

As we begin approaching the CESM3/CLM6 release should we also stop supporting CLM4.5 physics?

This is a broader discussion for the LMWG to discuss, but I thought of using the discussion feature in github to start taking everyone's temperature on this topic.

Besides voting, please add your thoughts to the comment section below.

[samsrabin]

From a search of "CLM45" in the Github issues, it looks like only #596 is CLM45-only, but I'm unsure of even that.

[ekluzek]

@wwieder this is a good question. I'm not sure of the answer either. And I don't think I should vote, as the most important thing is if this is useful to the scientific community. If it is we'll support it on the SE side, and if not we can drop it from testing and then from the code.

I will note that in CLM5.0 we supported three options: clm4_0, clm4_5 ADN clm5_0. So supporting: clm4_5, clm5_0, and clm6_0 (what we will eventually rename clm5_1 to) would make sense. And for the CLM5.0 release simulations were done for all three of those configurations, so I would imagine we'd want to do the same here.

Also in the case of CLM5.0, the clm4_5 and following code based had significantly diverged from clm4_0, so supporting clm4_0 long term was not feasible, after CLM5.0. So we dropped it as soon as we could. However, clm4_5, clm5_0, and clm6_0 are all in the same code base and the amount of code you have to support for clm4_5 is minimal compared to how clm4_0 was setup. So it's reasonable to support all three going forward whereas it was NOT with clm4_0.

[dlawrenncar]

It seems like it comes down to, as it often does, to what is meant by support. We could maintain the code, which as Erik suggests would not be that much code and would not be that hard to maintain. But, what we might want to do is drop support for users. So, anyone who wanted to run CLM4.5 would be welcome to, but we wouldn't help sort out problems or interpret results and we wouldn't necessarily fix broken code either.

…

On Mon, Feb 12, 2024 at 2:23 PM Erik Kluzek ***@***.***> wrote: @wwieder <https://github.com/wwieder> this is a good question. I'm not sure of the answer either. And I don't think I should vote, as the most important thing is if this is useful to the scientific community. If it is we'll support it on the SE side, and if not we can drop it from testing and then from the code. I will note that in CLM5.0 we supported three options: clm4_0, clm4_5 ADN clm5_0. So supporting: clm4_5, clm5_0, and clm6_0 (what we will eventually rename clm5_1 to) would make sense. And for the CLM5.0 release simulations were done for all three of those configurations, so I would imagine we'd want to do the same here. Also in the case of CLM5.0, the clm4_5 and following code based had significantly diverged from clm4_0, so supporting clm4_0 long term was not feasible, after CLM5.0. So we dropped it as soon as we could. However, clm4_5, clm5_0, and clm6_0 are all in the same code base and the amount of code you have to support for clm4_5 is minimal compared to how clm4_0 was setup. So it's reasonable to support all three going forward whereas it was NOT with clm4_0. — Reply to this email directly, view it on GitHub <#2359 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVGGEWIFMVGYPS3WVJ3YTKB6XAVCNFSM6AAAAABDE7FYA2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DINBXGAZTA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>