-
Notifications
You must be signed in to change notification settings - Fork 132
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
Fix history and restart frequency, new features to scripts #610
Conversation
- Fix bugs in history/restart frequency associated with new calendar (CICE-Consortium#589) - Define frequency in absolute terms relative to 0000-01-01-00000 and document (CICE-Consortium#589) - Update set_nml.histall to include hourly output (CICE-Consortium#589) - Update test scripts to cleanly abort if run fails where possible (CICE-Consortium#608) - Update decomp test so it's rerunable, remove restart at start of run (CICE-Consortium#601) - Add ability to do bfbcomp tests with additional options set on command line (CICE-Consortium#569) - Update documentation of calendar frequency computation, calendar types, and closed boundaries (CICE-Consortium#541) - Add optional doabort flag to abort_ice to control whether the method aborts. This is useful for testing and code coverage statistics, although doabort=.false. will not call the actual abort method, but we can test the interfaces and rest of the code.
reference data for history and restart output. Defaults are 'zero' and 'init' respectively for hist and dump. Setting histfreq_base to 'zero' allows for consistent output across multiple runs. Setting dumpfreq_base to 'init' allows the standard testing which requires restarts be written, for example, 5 days after the start of the run. - Remove extra abort calls in bcstchk and sumchk on runs that complete fine but don't pass checks. These aborts should never have been there. - Update documentation.
@apcraig I've tested this in ufs-weather; I can now obtain 6hrly history files as before. Everything is b4b with our current baselines. |
Thanks @DeniseWorthen! |
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.
This generally looks okay to me. This could be done in a later PR, but I think the documentation needs a bit more information added about how the various calendar and restart options interact with each other. E.g. the table showing ice_ic, runtype and restart values could be expanded to indicate how the *_init dates play in, depending on use_restart_time (or show some examples). Are use_restart_time and dumpfreq_base completely independent?
@@ -1116,6 +1121,16 @@ subroutine input_data | |||
abort_list = trim(abort_list)//":22" | |||
endif | |||
|
|||
if(histfreq_base /= 'init' .and. histfreq_base /= 'zero') then |
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.
Since you check these in ice_calendar.F90, do you need to do them here?
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.
We don't, but I think it's reasonable to trap them during the initialization for efficiency. I think it's also proper to have the if loop in the calendar operate only on valid values.
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.
Thanks for these fixes @apcraig. I left a few notes but is mostly looks good. It's nice to see that it was not too hard to add support for both 'zero' and 'init' modes.
cicecore/shared/ice_calendar.F90
Outdated
dumpfreq_base, & ! restart frequency basetime ('zero', 'init') | ||
histfreq_base, & ! history frequency basetime ('zero', 'init') | ||
calendar_type ! differentiates Gregorian from other calendars | ||
! default = ' ' | ||
dumpfreq_base = 'zero', & ! restart frequency basetime ('zero', 'init') | ||
histfreq_base = 'init', & ! history frequency basetime ('zero', 'init') | ||
calendar_type ! define calendar type |
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.
why are the default values set here in ice_calendar
instead of in ice_init
as for other namelist flags ?
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.
They are also set in ice_init in the standard method. The reason that I set them here as well is to help the unit testing work better. calchk doesn't go thru any CICE initialization, so having defaults set here means I don't have to explicitly set them when I run the calchk unit test. One could argue whether that is the best way to do it. I also made a similar change to ndtd in ice_calendar.
"a_rapid_mode", ":math:`{\bullet}` brine channel diameter", "" | ||
"add_mpi_barriers", ":math:`\bullet` turns on MPI barriers for communication throttling", "" | ||
"advection", ":math:`\bullet` type of advection algorithm used (‘remap’ or ‘upwind’)", "remap" | ||
"a_rapid_mode", "brine channel diameter", "" | ||
"add_mpi_barriers", "turns on MPI barriers for communication throttling", "" | ||
"advection", "type of advection algorithm used (‘remap’ or ‘upwind’)", "remap" |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
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.
Interesting, I couldn't figure out why those bullets were there. It just looked like some had them and others didn't which seemed inconsistent to me. So I just removed them all. If we need to restore and review all the current variables, we can do that. Sorry about that.
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 think it's ok to delete them, and remove the mention about them at the top of the index, like you do in your latest version. Closing this conversation.
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.
... turns out I can't do that :p It turns out I instead hid my first comment above.
- restart namelist is deprecated, now computed internally - modify initial/continue init checks and set restart and use_restart_time as needed - create compute_relative_elapsed method in ice_calendar to improve code reuse - update documentation with regard to initial/continue modes
I have updated the implementation. I fixed several issues and also updated the initial/restart implementation after discussions with @eclare108213. The documentation was also update to reflect these changes. |
Also, I am running a full test suite on cheyenne now. |
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.
Thanks for these additional clean-ups Tony, this was really long overdue I think. Especially the "Ice initialization" table in the doc, the new version is really clearer. I think it makes sense to start deprecating the restart
namelist flag, since it was reset already internally under several conditions.
@apcraig @eclare108213 @dabail10 : I remembered this issue: #527. I just skimmed it and from what I understand it would be closed by this here PR with the latest changes to the restart flags, right ? If so we could also check it in the list at #567. |
I think this does address #527. In general, we could support use_restart_time=.false. with runtype='continue' and were up to now. But after some discussion, it was decided to simplify the options a bit, so we're eliminating that feature (for now). The issue in #527 could (should) have also been solved by modifications in the nuopc cap or changes to the namelist generation in CESM, and maybe that was done or is still worth doing. Unless other disagree, I think this can close 527 and will add that comment in the PR documentation. |
I tested the latest changes and everything still works. This could be merged unless there are other comments to address. |
Unless I hear any concerns or someone gets to it before me, I'll merge this PR in the next couple days. Thanks. |
Thanks a lot for these fixes @apcraig ! The history frequency bug was the last missing bit for me to wrap up the first phase of our project for updating to CICE6 in our forecasting systems! |
PR checklist
Short (1 sentence) summary of your PR:
Fix history and restart frequency, update scripts, update unit tests
Developer(s):
apcraig
Suggest PR reviewers from list in the column to the right.
Please copy the PR test results link or provide a summary of testing completed below.
All tests are bit-for-bit on cheyenne with full test suite three compilers, https://github.com/CICE-Consortium/Test-Results/wiki/cice_by_hash_forks#0cd4402af2528228ea3aa33dc34e426e5a353474
How much do the PR code changes differ from the unmodified code?
Does this PR create or have dependencies on Icepack or any other models?
Does this PR add any new test cases?
Is the documentation being updated? ("Documentation" includes information on the wiki or in the .rst files from doc/source/, which are used to create the online technical docs at https://readthedocs.org/projects/cice-consortium-cice/. A test build of the technical docs will be performed as part of the PR testing.)
Please provide any additional information or relevant details below:
Fix history/restart frequency bugs
Update initial/restart logic
New features in scripts
Update documentation
Update unit tests