Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Consider aborting with an error if the user tries to set cisminputfile in a branch run

Open
  • Is something wrong?
#152 1 comment 0 reactions 0 assignees View on GitHub

@billsacks is already working on this.

Since Oct 22, 2026.

  • #153 by @billsacks — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
fortran
Domain
backend

Research direction

Start with the buildnml logic that sets cisminputfile, then read source_glc/glc_InitMod.F90 around the linked lines and check how branch runs handle restart input. The issue proposes aborting when a user override is attempted, but asks whether branch run overrides can be legitimate; clarify that behavior before changing it. Done means branch runs cannot silently initialize from unintended older input, with the behavior verified for the relevant run types.

Written by the indexing model from the issue text.

Description

I'm not positive what the right thing is to do here, but am opening this issue to document a possible failure mode and discuss what should be done.

This emerges from a fully-coupled case run by @gunterl where the model was dying in CTSM at the start of day 2 with the message, "found unexpected non-zero delta mid-year". The problem was that @gunterl created a branch run by cloning the hybrid run that it was branching from, and that hybrid run had set cisminputfile in user_nl_cism, and that setting of cisminputfile was kept in place in the branch run. Although I haven't done a careful diagnosis of how this caused the error, I think I understand what's happening: When the branch run boots up, it initially sends fields to CTSM based on the cpl restart file. But CISM is incorrectly initializing based on the initial conditions in cisminputfile rather than from its restart file. This resets CISM's state to some older initial conditions rather than the correct state for the branch run. Then, when CISM first communicates with the mediator in the run loop - at the end of day 1 - it sends this older state. CTSM sees this change in GLC state at the start of day 2, and this triggers an error condition because CTSM is not expecting to see any area changes mid-year. I'm not positive of this whole sequence of events, but this makes sense to me as a possible chain. If that's right, then note that the abort in CTSM is just a symptom of a bigger issue, which is that CISM was incorrectly re-initialized to the older cisminputfile in this run rather than using the restart file from the case its branching from, which I assume was not intended.

CISM's buildnml has logic that sets cisminputfile to the appropriate CISM restart file in a branch run, but this logic allows the user to override this setting in user_nl_cism. In a restart / continue run, it looks like this cisminputfile setting is ignored, but it looks like the logic for this ignoring is based solely on whether it's a restart / continue run, not a branch run:

https://github.com/ESCOMP/CISM-wrapper/blob/d6497d2bc254bdfed6dbc876761e2918271ba033/source_glc/glc_InitMod.F90#L286-L287

Incidentally, this is set to branch in some cases, but it doesn't look like this runtype="branch" setting is ever checked:

https://github.com/ESCOMP/CISM-wrapper/blob/d6497d2bc254bdfed6dbc876761e2918271ba033/drivers/cpl/nuopc/glc_comp_nuopc.F90#L322-L323

It seems like an attempt to override cisminputfile in a branch run is usually a mistake, and so I propose having CISM's buildnml abort with an error if the user tries to do this. I'm not sure the best way to do this. Maybe checking the final cisminputfile against the default value, and aborting if those differ in a branch run? Or are there legitimate cases when a user would want to override cisminputfile in a branch run that need to be allowed? With the current code in CMEPS and CTSM, I believe this will cause problems in any configuration with CTSM, but I suppose could be done in a T compset... but it's not clear to me why you'd want to set up a branch run then.

Dominant language
Fortran
Stars
4
Forks
18
Avg merge
1d 20h
Merged PRs (30d)
2

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ESCOMP/CISM-wrapper

All issues in ESCOMP/CISM-wrapper

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.