Repository navigation
Update solver in CTSM #2422
Description
We need to update the decades old quadratic solver used in CTSM.
Definition of Done:
- Change the solver out in FATES (use code freely availble from the Navy)
- Remove the LUNA instance of quadratic, to use Quadratic under utils
- Update the solver code in quadratic so that it's independent of copyrighted solutions
- Also handle the tridiagonal solver
- Handle the Brent solver
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
ekluzek commentedon Mar 14, 2024
In ctsm5.1.dev173, a new Navy solver was brought in. We might as well use it for both FATES and non-FATES.
See here...
https://github.com/NGEET/fates/blob/main/main/FatesUtilsMod.F90
ekluzek commentedon Mar 14, 2024
In discussion this morning, we thought a better solution would be to copy the code to the CESM share code.
If we have CTSM use FATES we end up with a double dependency in both directions which is bad. In this case it's a simple utility layer of FATES, so not as intertwined into FATES as other FATES layers.
The problem here is that fates_log() is being used as part of FatesGlobals, so we could NOT use it directly in CTSM.
ekluzek commentedon Mar 14, 2024
@rgknox our plan right now is to copy it to share code and then have a CTSM update that points to the new share version with it in it. Let us know thoughts on that.
rgknox commentedon Mar 15, 2024
hmmm, I'm sure there is some way to make this work. If we call these routines in FATES from the share, than this needs to be in the shared code for ELM and NORESM as well.
ekluzek commentedon Mar 15, 2024
Yes exactly. We weren't sure if they use the same share version or not. I'm guessing that ELM likely has their own version of share? But, we thought NORESMF might use the same one as CESM. Could you check?
ekluzek commentedon Mar 15, 2024
In order to get this to work so that we'd share it from FATES, we'd need to do something like have a directory under FATES for a utility layer that doesn't allow use of ANY other FATES code. So for example here, the use of fates_log() would be replaced by passing the log unit into the subroutine. The rule for that directory would be that anything in that directory is completely independent of FATES.
We do always build with FATES -- we just don't always initialize FATES -- so we can't be using higher level FATES subroutines and objects in non-FATES CTSM. So we'd need a directory that's independent.
The other way to do it would be to have a new share external that all FATES models would use. That would also work, but would be adding in something new, that would take a bit of organizing around.
@adrifoster what do you think about this idea?
mvdebolskiy commentedon Mar 15, 2024
@rgknox we are checking out a fork of the CESM_share in NORESM. So there is no problem to pull from the upstream for us.
ekluzek commentedon Feb 18, 2026
Bringing this up again, as we want to make sure the update won't change answers. If it does change answers we'll want it in right away.
1 remaining item
samsrabin commentedon Feb 19, 2026
Per SE meeting today, this doesn't change answers.
wwieder commentedon Oct 1, 2026
There's no PR for this. @briandobbins and @ekluzek what is the last acceptable deadline for this?
ekluzek commentedon Oct 1, 2026
This is something that just makes lawyers happy, and it sounds like @briandobbins wanted it in for the cesm3_0_release. So that we don't have it visible in one of our big model releases.
wwieder commentedon Oct 2, 2026
OK, do we have a PR that we can test and slot in quickly?
ekluzek commentedon Oct 10, 2026
I started some work on this Thursday, and have a PR now for this. It turns out the Quadratic formulation wasn't written up as code in NR, and the math isn't copyrightable. From Claude (and others) it looks like merely changing comments and variable names isn't sufficient, you have to do a more substantial rewrite. But, using the same alogrithm and formulas there's only so much that can be done to show the code is different.
ekluzek commentedon Oct 10, 2026
In looking for references for this, I realized that the Tridiagonal solver is also from NR. So it needs to be handled as well.
ekluzek commentedon Oct 10, 2026
And it looks like the Brent solver in Photosynthesis is likely from NR, so may need to be handled. The version we have is highly customized for CLM, so will take some evaluation to determine if it's OK or not.