MPAS dycore timer resets for restart runs
Maintainers usually reply within 3 days
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- fortran
- Domain
- backend
Research direction
The payload names no source files. Start with the mpas_do_restart namelist entry, which is always false on restart runs, and find where the MPAS time-step diagnostics in atm.log take their calendar from. Reproduce with a restart run (CONTINUE_RUN = TRUE, RESUBMIT > 0) and compare the log timestamps with the history tape times. Done means the log calendar continues from the restart time, and the restart flag is set correctly.
Written by the indexing model from the issue text.
Description
What happened?
When restarting a run with mpas (CONTINUE_RUN = TRUE; RESUBMIT>0), the time-step level diagnostics from mpas in the atm.log.* file resets the internal mpas calendar to RUN_STARTDATE at the start of the resubmit. This has not lead to any issues in practice, as the CAM timers are correct in the history tapes.
What are the steps to reproduce the bug?
Setup a start-up run w/ RESUBMIT>0, and perusethe atm.log.* file for the restarted run.
What CAM tag were you using?
cam6_4_212
What machine were you running CAM on?
CISL machine (e.g. derecho)
What compiler were you using?
Intel
Path to a case directory, if applicable
No response
Will you be addressing this bug yourself?
No
Extra info
This namelist may be relevant, as it is always false (even on restart runs). I don't know what it does.
<entry id="mpas_do_restart" type="logical" category="mpas"
group="restart" valid_values="">
Whether this run with the MPAS dycore is to restart from a previous restart
file or not.
Default: Set by build-namelist.
</entry>
- Dominant language
- No language data
- Stars
- 93
- Forks
- 186
- Avg merge
- 5d 3h
- Merged PRs (30d)
- 18
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ESCOMP/CAM
-
build-namelist hangs (infinite loop) on #-commented line in user_nl_camPossibly taken @jtruesdal claimed this 20 days ago. Openbug misc tag Must have CESM3
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
ESCOMP/CAM#1701 · 2 comments · 1 assignee ·
Maintainers usually reply within 3 days
-
CoupledEval3 Must have CESM3
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 3 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 48/100
Maintainers usually reply within 3 days
-
Remove for_testing_allow_non_annual_changes from user_nl_clmPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 1/5 Under an hour Newbie friendliness 25/100
Maintainers usually reply within 3 days
-
after CESM3_0 enhancement
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Maintainers usually reply within 3 days
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
elixir-ecto/db_connection#361 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
glossyio/traffic-monitor#255 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
juice-shop/juice-shop#3706 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
ProcessCopy sets SyncState of origin Process to not_syncPossibly taken @stefane2741 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day