-
Notifications
You must be signed in to change notification settings - Fork 321
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
New params file with changes for Meier roughness, MIMICS, and SNICAR, and changes to leafcn and k*_nonmyc #2258
Conversation
I have pushed steps (1) and (2) to the PR. |
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.
Should we bother lining up "observational" with the rest of the variable descriptions (off by one space).
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.
Yeah, this is the vertical alignment question. Which I am confused about our current status on. We used to make sure things aligned vertically. But, recently I had understood we were going to go away from that. But, then we have indications that we aren't. So we need to nail this down and all agree on what we are doing.
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.
One comment, otherwise looks good, thanks.
Test-suites:
|
Yes, I think so, Sam |
I looked through the Meier tests in the cheyenne test-suite and found no exact Clm51 equivalents, so I will keep them without the reference to Meier2022_surf_rough, because the latter is now default for clm51. One test failed on izumi: Four tests failed on cheyenne:
The first three I fixed with with a code change that permits htop < 1e-10 for istcrop. The fourth should have been a clm51 test, but I get This expected failure should be a clm51 test, so I will rerun and generate a baseline. I'm rerunning the four clm51 tests that had Meier testmods, now without those testmods. I hope I got everything... |
Yes, this is correct the original card in upcoming tags had this in it:
The commit in question is: To use the commit you need to use cherry-pick so it only brings in that one change, rather than all the changes on CESM3_dev. Or you can copy the changes in by hand. cherry-pick keeps the history, that's it's advantage... |
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 have a question and then an important change to make. Since, it's so simple I'm approving it as it is so you can immediately move forward after the one change.
Nice, to see this coming in.
@@ -1,4 +1,2 @@ | |||
z0param_method = 'Meier2022' |
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.
Probably should remove this test mod since the clm4_5 and clm5_0 tests already are doing Meier off, and clm5_1 with Meier on. So both options are covered. So there's no reason for a test mod that does one or the other...
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.
Done
@slevis-lmwg since you've run testing and the changes are still relatively modest I think we should go forward with this. But, it does look like there are a mix of changes that could be done as bit-for-bit and others that truly are answer changing. It's good to make the answer changes as small as possible, and do the bit-for-bit parts separate, just in case there's a mistake in the bit-for-bit part. As then it'll show up as an unexpected answer change. That kind of thing is hidden when there's a mix of both. For example, the move of fresh_snw_rds_max to the param file could be done as a bit-for-bit part. If it changes answers you then know there's a mistake in there. But, it's hidden when it comes in with answer changes. It does look like you marked clm4_5 and clm5_0 as changing answers. Is that expected and is it possible to make them identical to dev153? If they can be made identical that would ensure that the bit-for-bit parts are bit-for-bit as expected. |
@@ -17,15 +17,6 @@ | |||
<option name="wallclock">00:20:00</option> | |||
</options> | |||
</test> | |||
<test name="SMS_D_Ln6" grid="f09_g17" compset="I1850Clm50BgcNoAnthro" testmods="clm/Meier2022_surf_rough"> |
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.
Removing the Meier testmods made this test redundant as a clm50 test, so I removed it.
(I did first try changing to a clm51 test and got Invalid compset name, I1850Clm51BgcNoAnthro
.)
Due to updating some tests and then generating baselines for them after running the test-suites, I am rerunning the test-suites and comparing against ctsm5.1.dev154. @ekluzek when I'm satisfied with the results, I will look into the feasibility of your suggestion of separating the parts of this PR that should be bfb. |
Here are my thoughts in the same order that this PR's commits went in: @ekluzek I see in your post that you're suggesting letting this through without additional testing at this point. I do think that additional testing would be convoluted and time consuming but doable. How about I wait for your confirmation (I could also meet if you prefer) by beginning of tomorrow, before moving ahead with the tag? |
From the above, I started a relatively easy test on izumi: Update: The above passed bfb against dev154 on izumi (12 gnu, 18 intel, and 32 nag tests). |
New clm5_1 params file with new parameters and with modified values of existing parameters. | ||
New clm5_0 and clm4_5 params files with new parameters for SNICAR. | ||
./rimport on the new params files fails with "No space left on device" but the 4 files are safe here: | ||
/glade/u/home/slevis/paramfiles/*_params.c231117.nc |
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.
Final comment before I merge:
./rimport on the new params files fails with "No space left on device"
The files are safe in my home directory: /glade/u/home/slevis/paramfiles.
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.
Update I have now completed this pending item:
./rimport -file lnd/clm2/paramdata/clm45_params.c231117.nc
./rimport -file lnd/clm2/paramdata/clm50_params.c231117.nc
./rimport -file lnd/clm2/paramdata/ctsm51_params.c231117.nc
./rimport -file lnd/clm2/paramdata/ctsm51_ciso_cwd_hr_params.c231117.nc
New params files for Meier roughness, MIMICS, SNICAR, and with changes to leafcn and k*_nonmyc 1) Start using existing new params file for Meier roughness: /glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/paramdata/ctsm51_params.RMz0.c231011.nc and include bug-fix ESCOMP#2219 2) Update forcing heights per ESCOMP#2071. 3) Update params file for MIMICS per ESCOMP#1845. 4) Make leafcn for pfts 15 and 16 the same per ESCOMP#2184. 5) Switch the values of params kc_nonmyc and kn_nonmyc per ESCOMP#2120. 6) Move SNICAR parameters to params file per ESCOMP#2247. Changes answers. Details in PR ESCOMP#2258 and in the ChangeLog.
Description of changes
/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/paramdata/ctsm51_params.RMz0.c231011.nc
and include bug-fix Meier roughness changes answers on processor count #2219
Specific notes
Contributors other than yourself, if any:
@ekluzek @olyson @wwieder @ecaas @cenlinhe others?
CTSM Issues Fixed (include github issue #):
Fixes #2219
Fixes #2071
Fixes #1845
Fixes #2184
Fixes #2120
Fixes #2247
Are answers expected to change (and if so in what way)? YES.
Any User Interface Changes (namelist or namelist defaults changes)?
New params file.
Testing performed, if any:
The answer-changes discussion above pretty much covers the current extent of testing.
After I merge this PR, I will run an Answer-changing simulation to compare with the model before this merge.