ctsm5.3.019: Stop running 0th time step

[olyson]

Description of changes

Stop running 0th time step.

Specific notes

See discussion in #925
DONE Note that "!KO" comments are still to be removed.

Contributors other than yourself, if any: @billsacks

CTSM Issues Fixed (include github issue #):
Fixes #925

Are answers expected to change (and if so in what way)? Yes, more than roundoff.

Any User Interface Changes (namelist or namelist defaults changes)? No

Testing performed, if any:
See discussion in #925

[billsacks]

Thanks a lot for this work, @olyson !

Are there any pieces of this that you feel warrant a careful review - i.e., that you'd like someone else to think about (if so, I would probably ask someone else to do that so that I can stay focused on some ESMF work for now)- or are you comfortable enough with the changes you made that a quick look-over should be sufficient?

Can you please go ahead and remove the !KO comments when you get a chance?

[billsacks]

From discussion today: @olyson feels reasonably confident that these changes are correct.

@samsrabin would like us to run ctsm_sci - or at least his new test - to make sure that this change doesn't break that.

[olyson]

We agreed to leave my comments in for now to help @ekluzek perform his review and understand the reasoning behind the changes, then remove them after that.

[olyson]

@olyson will run the full test suite on this before @ekluzek 's review.

[billsacks]

I just skimmed through some pieces of this (not a full review, but just some selective checks). Thank you very much for your careful work on this @olyson and especially for the comments describing your reasoning!

I did a quick check that the changes here are consistent with some specific things I raised in #925 . One question I had from skimming back through the comments in #925 is if you remember if you did the searches through the code that I mentioned in #925 (comment):

I think when I did my earlier search I looked for nstep == 0 but didn't look for similar things like nstep /= 0, nstep > 0, nstep >= 1, etc. We'll need to check for uses like that.

[olyson]

Full aux_clm test suite results (output of ./parse_cime.cs.status tests_0803-171434ch/cs.status -s):

Test summary
176 Total tests
174 Tests passed
172 Tests compare different to baseline
0 Tests are new where there is no baseline
1 Tests pending
1 Tests failed

The pending test is EXPECTED as is the failed test.
The two tests that did not compare different to baseline are:
FUNITCTSM_P1x1.f10_f10_mg37.I2000Clm50Sp.cheyenne_intel
PFS_Ld10_PS.f19_g17.I2000Clm50BgcCrop.cheyenne_intel

I'm not familiar with those two tests. Maybe someone will know why those might pass? Otherwise, I will look into it.

[billsacks]

Thanks @olyson !

It makes sense that the FUNIT test doesn't show BASELINE comparison failures: that is a weird test that just runs the unit tests, so doesn't actually do baseline comparisons.

As for the PFS test: I think it might not actually produce any history files (by design)... so again, it makes sense that there are no BASELINE failures for that since there is nothing to compare.

[olyson]

Yep, I don't see any history files for the PFS test, thanks.

[slevis-lmwg]

STILL NEED THIS FOR rtm, BUT ALSO FOR mosart WHILE ITS NEXT TAG IS PENDING

Before starting the test-suites, include Erik's mosart/rtm bug fix:
src/riverroute/mosart_restfile.F90

@@ -248,7 +248,7 @@ contains
 
       if (mainproc) then
          call get_curr_date(yr, mon, day, tod)
-         write(timestamp,'(".",i4.4,"-",i2.2,"-",i2.2,"-",i5.5)'),yr,mon,day,tod
+         write(timestamp,'(".",i4.4,"-",i2.2,"-",i2.2,"-",i5.5)') yr,mon,day,tod
          locfn = './'// trim(rpntfil)//trim(inst_suffix)//timestamp

src/riverroute/RtmRestFile.F90

@@ -255,7 +255,7 @@ contains
 
     if (masterproc) then
        call get_curr_date(yr, mon, day, tod)
-       write(timestamp,'(".",i4.4,"-",i2.2,"-",i2.2,"-",i5.5)'),yr,mon,day,tod
+       write(timestamp,'(".",i4.4,"-",i2.2,"-",i2.2,"-",i5.5)') yr,mon,day,tod
        locfn = './'// trim(rpntfil)//trim(inst_suffix)//timestamp

[ekluzek]

@slevis-lmwg and I are going over this, and I'm marking this with approve so it can move forward. I made a couple comments on things to do. And the conversation with a checkbox should be resolved.

I thought there were good comments around the code here. The unneeded old code and comments were removed. So this looks good.

The RXCROP tests still won't work there, but will in the next one. This will be ctsm5.3.019 and they will work on ctsm5.3.020.

[slevis-lmwg]

derecho testing

PASS ./build-namelist_test.pl
PASS ./run_ctsm_py_tests
PASS make black and lint (though lint gave 2 warnings)
OK ./run_sys_tests -s aux_clm -c ctsm5.3.018 -g ctsm5.3.019
OK ./run_sys_tests -s mosart -c mosart1.1.06-ctsm5.3.018 -g mosart1.1.06-ctsm5.3.019
OK ./run_sys_tests -s rtm -c rtm1_0_84-ctsm5.3.018 -g rtm1_0_84-ctsm5.3.019

izumi testing

OK ./run_sys_tests -s mosart -c mosart1.1.06-ctsm5.3.018 -g mosart1.1.06-ctsm5.3.019
OK ./run_sys_tests -s aux_clm -c ctsm5.3.018 -g ctsm5.3.019

Check them with
./cs.status.fails | grep -v PASS | grep -v 'EXPECTED FAILURE' | grep -v '18: DI'
1st four OK using ./create_test

• In the ChangeLog, repeat the temporary issues that I reported in ctsm5.3.018 that I will resolve in ctsm5.3.020.

[ekluzek]

I'm trying out a new idea that we'll discuss next week. Since, this is the next tag in line I added the tagname to the title. This allows us to see the tagnames in the list of closed PR's. It might not always make sense to do this, and if the order changes or the tagname is changed, it'll have to be updated at least by the time the tag is made to keep it accurate. But, I think this will be helpful especially for closed PR's, and also usually for the next tag that's in line.

[slevis-lmwg]

@olyson I'm almost ready to merge your PR:

• Could you comment on my ChangeLog update or modify it further yourself?
• Anything else you can think of?
• As we discussed, we will test this code in an F-case with the latest cesm tag very soon. I am not clear whether that's already available, but let's follow up over the next few days.

[olyson]

Regarding the ChangeLog, it says that mosart and rtm changes are not bfb due to a bug. Does that imply that the changes due this PR alone are bfb? If so, should we say that explicitly? Or is that what you mean when you say the diffs will be eliminated in the next tag?
Given the recent problem with FATES and Meier, should we run FATES testing?

[slevis-lmwg]

Regarding the ChangeLog, it says that mosart and rtm changes are not bfb due to a bug. Does that imply that the changes due this PR alone are bfb? If so, should we say that explicitly? Or is that what you mean when you say the diffs will be eliminated in the next tag?
Given the recent problem with FATES and Meier, should we run FATES testing?

1. There are a few things going on:

• Izumi nag tests that failed to build due to a bug in rtm and mosart. I entered the fix manually in this PR to show that it does not change answers. The fix will go in with the modules update in ctsm5.3.020.
• We see diffs in mosart and cpl output that appear in two aux_clm tests with cism active and are discussed here:
  ctsm5.3.018: Change history time to be equal to the middle of the time bounds #2838 (comment)
  ctsl%rof_to_glc needs to be set before fldlist_add calls adding the Fgrg_rof? fields is done MOSART#103 (comment)
  These also get fixed with the modules update in ctsm5.3.020.
• I have added a new comment to the ChangeLog to indicate that the mosart and rtm code changes alone do not change answers here:

If the tag used for baseline comparisons was NOT the previous tag, note that here:
 I repeated the rtm & mosart test-suites with mosart1.1.04 instead of 06 and rtm1_0_82 instead of 84 (all else the same) and compared against the new baselines mosart1.1.06-ctsm5.3.019 and rtm1_0_84-ctsm5.3.019. These gave b4b identical answers.

2. Could you elaborate regarding the possible need for FATES testing in the google chat that we have going?

3. Regarding your question in our google chat about my recent commit f3a1dc6:
   The new rpointer file naming made this change necessary in continue and branch cases. Without the change, the model looked for rpointer files with a 01800 suffix and failed. This would have passed without the change prior to the new rpointer file naming due to the generic names used before. Let me know if you want to discuss this or anything else further.

[olyson]

1. Thanks for the explanation and the change to the log, that makes sense.
2. I don't really know if FATES testing is needed or not, I was just being cautious based on the recent problem encountered with Meier. Are there any FATES tests in aux_clm? If so, maybe that's good enough?
3. Good to know that the change was required due to the implementation of a new feature, thanks.

[slevis-lmwg]

2. I don't really know if FATES testing is needed or not, I was just being cautious based on the recent problem encountered with Meier. Are there any FATES tests in aux_clm? If so, maybe that's good enough?

I will go with "not needed" for two reasons:

• Yes, there are a few Fates tests in aux_clm
• I will run the fates test-suite before merging ctsm5.3.020

[olyson]

2. I don't really know if FATES testing is needed or not, I was just being cautious based on the recent problem encountered with Meier. Are there any FATES tests in aux_clm? If so, maybe that's good enough?

I will go with "not needed" for two reasons:

• Yes, there are a few Fates tests in aux_clm
• I will run the fates test-suite before merging ctsm5.3.020

Sounds good then, thanks.

[slevis-lmwg]

Thanks @olyson and @ekluzek :-)