-
Notifications
You must be signed in to change notification settings - Fork 312
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
change soil moisture initialization logic for FATES configurations #1962
Conversation
We're wondering we can / should keep the HLM and FATES initialization the same to avoid confusion for users? This seems like it warrants a more scientific-focused discussion with both FATES and HLM teams? |
We also wondered if this shouldn't be a namelist item of some sort to make it more obvious what the starting state is being set to. |
Right. In principle the initial soil moisture is another hidden parameter that could be brought into the PPE infrastructure. In email discussions with @dlawrenncar and @swensosc, it does seem like changing the initial amount will lead to changes that persist over the long term in the permafrost soil thermal and hydrologic dynamics. So if the goal is to use consistent values between FATES and non-FATES configurations, then exploring that would need to be done. The very dry values we are using now are leading to problems in FATES runs; since non-FATES configurations don't really represent mortality, they aren't really sensitive to the issue. @swensosc proposed one possibility of initializing at field capacity, so a fixed matric potential rather than volumetric water content. That would seem like a good long-term solution to me, to initialize to some uniform matric potential, with a default value of field capacity, but also make the initial matric potential a PPE parameter that could be explored. But again, that would lead to changes in behavior as compared to the current simulations. |
Per the ctsm software meeting discussion today, we agreed to bring in this PR as is and continue the broader science-focused discussion in a new repo issue/discussion. I'll use this PR as a vehicle to update fates to the latest API updates as well. |
Update externals and minor fixes Main change is to update externals to cesm2_3_alpha12c-ish. Doing this exposed a few issues that are also fixed here. Also, reduce GU_LULCC tests down to a single test.
Testing the |
Almost all That said, one of our longer, higher resolution exact restart tests ( |
Re-running this test with a greater wall clock allowed it to complete. It ran as expected taking 42.6 minutes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't think of anything else this needs. Thanks for also updating the FATES tag and associated parameter file.
One tests passed although it was expected to fail: There was one unexpected failure, Folder on cheyenne: |
@glemieux odd that the UNIT tests worked for you, but it had been failing for @billsacks. Maybe CISL fixed something on the system? Or it's a user dependent thing? On the other issue it's failing in this set of commands...
Try running each of those commands separately on the command line and see what fails. You might also just ./py_env_create
conda activate ctsm_pylib
cd python
make test and see what happens... |
Thanks @ekluzek. It looks like everything worked as expected:
Maybe this was a glitch of some sort? Should I try and manually run |
Possibly what happened was that you hadn't run py_env_create before so you needed to run it by hand? Could that be the base? We have a long list of things that happen in that line in the script. Possibly the script should do them separately, so you know which one fails. |
Oh, I didn't realize we needed to run |
Yep, this is a new thing that you need to do. We possibly need more documentation and advice given about the need to do it. |
I'm running into an issue with the nag compiler izumi tests. I'm getting the following error:
We've definitely increased the number of variables in the |
@glemieux yes I saw this with the CN matrix work. There is a limit for nag on how many lines you can have in those continue statements. What we had to do for CN matrix was to have more than one associate statement that you nest. It's annoying but not that much different and just adds a couple end associate statements at the subroutine close. |
I'll be testing NGEET/fates#1009 and updating the externals pointer to the integrated for fix the above issue prior to continuing with this PR. |
Regarding the FUNIT tests: Brian Vanderwende in CISL made a system change that should get them working again. He said:
So I have closed #1972. @glemieux I opened a PR with some changes that should be merged now that this is resolved: #1978 . Can you either (a) cherry-pick the single commit on that branch into the branch you're working on here, or (b) give me the go-ahead to merge #1978 when it won't interfere with your work? |
Thanks for the heads up @billsacks. I'll cherry-pick your commit into this PR. |
This tag includes a fix to avoid line continuation issues seen on izumi.
Testing on Cheyenne is complete. All expected non-fates test pass B4B for the Folders on Cheyenne:
UPDATE: waiting on |
Testing on izumi is complete. As expected all non-fates tests are b4b for the Folders on Izumi:
|
Folder on cheyenne:
@ekluzek this should be good to go now. |
Is this new logic only applicable to FATES? It seems like we could
potentially use the same logic in big leaf CTSM to avoid a divergence
between the two configurations. Something to discuss.
…On Wed, Apr 5, 2023 at 1:35 PM Erik Kluzek ***@***.***> wrote:
Merged #1962 <#1962> into master.
—
Reply to this email directly, view it on GitHub
<#1962 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFABYVCNKENSXUEQ4TT27L3W7XCQPANCNFSM6AAAAAAVSA2IRQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@dlawrenncar yes it's only for FATES and is considered a temporary solution. This just allows them to run for now. We've had some discussion about better long term solutions, but they will require some study. And likely someone identified to work on this. See comments near the top of this issue. We thought this should be discussed at an up and coming CTSM science meeting. |
This PR changes the logic for soil moisture initialization to initialize with wetter soils (75% of saturated water content, as opposed to 15% of absolute water content) for all FATES configurations. The rationale for this is that in FATES-nocomp simulations, @JessicaNeedham was finding very high initial mortality rates in some seasonal tropical forest regions, and she traced it back to the initial soil moisture killing off plants before the ecosystem could get established. More info at NGEET/fates#994.
Description of changes
This soil moisture value was already in use for FATES-Hydro, this PF just updates it to be used for all FATES configurations. I've run it and the code does the intended thing, which is to make soils considerably wetter across the world during the initial period from a cold-start spinup.
The thing I am curious about is whether there are any longer-term implications to the soil moisture, in particular in the permafrost region. I haven't tested this for a long period yet, but I wonder how much the initial soil moisture gets locked in for permafrost soil layers, and thus how sensitive they are to initial conditions even after long spinup? @swensosc and @dlawrenncar probably know the answer to this.
Specific notes
Contributors other than yourself, if any: @JessicaNeedham
CTSMFATES Issues Fixed (include github issue #): NGEET/fates#994Are answers expected to change (and if so in what way)? Yes, in all non-hydro FATES configurations (the change to initial soil moisture is already the case for FATES-hydro and so wouldn't change anything there)
Any User Interface Changes (namelist or namelist defaults changes)? No
Testing performed, if any:
@JessicaNeedham has done more complete testing in E3SM-FATES to show that it fixes the initial high mortality bias. I have run this code in CLM-FATES and it does increase soil moisture as intended. I have not run it through any test suites.