ctsm5.4.029: Merge b4bdev 20260326#3894
Conversation
Merge b4b-dev to master Purpose and description of changes ---------------------------------- Merge b4b-dev to master: Important things coming in: - mizuRoute! (NOTE: mizuRoute is a River model (ROF in the CESM context) that can be run in place of MOSART or RTM) - Documentation updates - Move a few namelist parameters to the parameter file - move of X components for nuopc - mksurfdata_esmf for Gnu compiler - scripts for CRUJRA forcing to handle Antarctica/Greenland - SpinupStablity script update to handle FATES and SE grids - Update cdeps for access to CMIP7 CO2 - Tests for FATES Tree Recruitment Scheme (TRS) Main grids to use with mizuRoute: Default mizuRoute grids will use the half degree land-only mizuRoute grid that is the same resolution as the MOSART grid. - 5x5_amazon_r05 - is the small Amazon region for testing - 5x5_amazon_rHDMA - is the small Amazon region using the HDMA for mizuRoute - nldas2_nldas2_rUSGS_mnldas2 - is the Continental US grid with USGS Geospatial Fabric - f09_f09_rHDMA_mg17 - is the 2 degree grid with the medium resolution HDMA grid - f09_f09_rHDMAlk_mg17 - is the 2 degree grid with the medium resolution HDMA grid that includes lakes - hcru_hcru_rMERIT_mt13 - is the half degree grid with the high resolution MERIT grid Standard case to run with mizuRoute: grid=f09_f09_rHDMAlk_mg17 compset=I2000Clm60SpMizGs
Merge master 20240316
slevis resolved conflicts: tools/contrib/README.md
bfb: Bugfix for FatesSp compiled with intel
In tools/contrib remove popden.ncl and run_clmtowers; update the corresponding README
See if this removes the error in line 81
This comment was marked as outdated.
This comment was marked as outdated.
|
Numerous unexpected failures on derecho unfortunately: Based on this PR's changes, I attribute the failures to the changes in
UPDATE: ALL CONCERNS RESOLVED: The first failure in the list has these diffs in this file The second/third has these diffs in The fifth passed upon the first manual ./case.submit 15 has missing baselines |
|
Two unexpected failures on izumi:
|
|
@ekluzek summarizing the list of failures above that we need to discuss before further action: UPDATE: Erik and I met for 5 minutes to go over this, and we will follow up on Monday. |
|
@slevis-lmwg I looked over your test cases, mostly to see if your submodules were out of sync or something like that. They aren't so it's not something that simple. I think a next step would be to rerun the tests that are showing differences from the ctsm5.4.028 in a vanilla checkout of ctsm5.4.028 -- to see if that differs from the baselines I made. There might be something wrong with the baselines, so it would be good to double check that. I did a little checking on them, but didn't spot anything as problematic. But, rerunning a few of these tests would be a good verification. The updates in the submodules, are pretty limited. It's only ccs_config, cime, and pio. cime and pio don't usually change answers at this point. There was a change to the ERI test for cime, but it looked benign. The changes in ccs_config were also innocuous in this case, so I don't think it's that. But, the failing ERI test might be due to the cime update. So you could try it without the cime update. The change for ERI was in cime6.1.157, so you could also just remove that change to the eri test. Or do something like try cime6.1.156 If the mizuRoute baselines look fine, you should try them without the submodule updates and then maybe we track down which of the updates is causing the difference. So a few things to try and think about... |
|
The three tests with diffs, now testing in vanilla 025: The first has diffs in this file The second and third,
|
|
@ekluzek this is ready for approval. |
|
OK, I have some concerns that the MOSART would give a change in answers until you resubmit and then answers realign to the baseline. I don't see an existing issue for this problem. And the fact that it realigns means answers are OK. But, if it means that answers sometimes randomly change for MOSART that's a bit concerning. Especially if we don't know why. They only change in the DIRECT field which only matters when coupled to ocean, and it should be much smaller than the general discharge to ocean, so wouldn't be too impactful. So we should make an issue on this to monitor it on how often it happens. |
|
Similar to my comments on MOSART above, mizuRoute also seems like it can randomly change answers until you resubmit. The mizuRoute changes are larger though and it occurs in an SMS test and for more fields. So we should create an issue and monitor how often this happens. |
ekluzek
left a comment
ekluzek
left a comment
There was a problem hiding this comment.
Normally, b4b-dev merges are easy and easy to approve. In this one @slevis-lmwg had a bad draw with tests that needed to be resubmitted to get them to work. And concerningly there were changes to answers against baselines for MOSART in one test, and mizuRoute for two tests. They resolved with resubmission, but this might indicate a random problem where answers change for a ROF model. We'll open issues for those and monitor how often this happens. Those problems are certainly NOT due to any changes in here, and it looks like this PR just randomly exposed an existing issue.
The changes are straightforward here, most being documentation changes. And the code changes clear from the b4b-dev PR they correspond to.
So approving.
|
I will now create the recommended issues, before I finish b4b-dev. |
github-project-automation
bot
moved this from In Progress
to Done
in LMWG: Sprint Planning Board
github-project-automation
bot
moved this to Done (non release/external)
in CTSM: Upcoming tags
Merge b4b-dev to master - Various documentation updates - Update submodules to ones in cesm3_0_alpha08l - Bugfix for FatesSp compiled with intel PR ESCOMP#3894
6 participants
Description of changes
Specific notes
Contributors other than yourself, if any:
@huiqi-wang @ekluzek @ijaguirre @mvdebolskiy
CTSM Issues Fixed (include github issue #):
Resolves #3256
Resolves #3234
Resolves #3703
Resolves #2997
Resolves #3541
Resolves #3507
Are answers expected to change (and if so in what way)?
No
Any User Interface Changes (namelist or namelist defaults changes)?
No
Does this create a need to change or add documentation? Did you do so?
Much of this work involves updates to the documentation
Testing performed, if any:
./run_sys_tests -s aux_clm -c ctsm5.4.028 -g ctsm5.4.029on derecho./run_sys_tests -s aux_clm -c ctsm5.4.028 -g ctsm5.4.029on izumi