Stop running 0th time step

[olyson]

Description of changes

Stop running 0th time step.

Specific notes

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

Contributors other than yourself, if any: @billsacks

CTSM Issues Fixed (include github issue #): #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.

[billsacks]

• Great, thanks for this change. I agree with this and we can remove the above BACKWARDS_COMPATIBILITY comment.

[olyson]

Thanks, yes, I had a comment in #925 noting that I checked for those things:
"Reviewed the code for instances of nstep == 0, nstep == 1, nstep /= 0, nstep > 0, etc (with and without spaces), and is_first_step, and made changes as required."
There could be some combination I didn't think of, if you or anyone has one I'll re-check.
I've removed the BACKWARDS_COMPATIBILITY comment in my latest commit.

[billsacks]

Oops, sorry, I missed that in my skim back through that issue. Thank you!

[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.

[samsrabin]

@olyson Exactly, thanks!

[olyson]

I updated to ctsm5.1.dev147, then I ran ./manage_externals/checkout_externals and ended up with some not in a clean state (components/rtm and components/mosart tagged with "M"). I think that is because I forgot that I had local changes to rtm and mosart to handle zeroth time step for those components.
I have separate branches for rtm and mosart that takes care of those changes.
So, I'm wondering if I can/should just checkout the changed files and then run checkout_externals again. Is that the best way to handle that?

[samsrabin]

I think the best thing to do would be to push your updated RTM and MOSART branches to your forks of those repos, then point the zerothtstep Externals.cfg to those branches. The easiest thing to do might be to git stash in components/mosart and components/rtm, do the externals checkout, then do git stash apply in those same directories.

[olyson]

Ok, I chose the easiest thing. I believe my branch is now up to date with ctsm5.1.dev147.

[samsrabin]

Nice, thanks! If you go ahead and push, I'll submit a PR when my test is done.

[olyson]

It's pushed now.

[wwieder]

These are blocked because changes also need to be made on mosart on rtm.