Where each NorESM3 CMIP7 run stands, the steps every run goes through from GitHub issue to ESGF, and what the plan costs on Olivia and Betzy.
completed label.esgf, and the progress script has run since. A run with several members needs the label on an issue of each; until then the column shows how many have it, e.g. 1/3.The tracker has a column for each step below from QA on, under the same headings, as well as the run's Status and Progress. The progress script fills them all in: Status, Progress, cmip7prep and cmor4cmip7 from the files on NIRD, and the other steps from a label on the case's GitHub issue, named next to each step. Under each step, To decide lists what the group still has to agree on.
A case is named compset.resolution.version.issue.date, for example n1850Gaxg.LM.nor30b22.502.20260801:
LM for ne16pg3_tn14, MM for ne30pg3_tn14;nor30 for noresm3_0_, followed by the beta, e.g. b22 for beta22;Issues go in NorESMhub/noresm_cmip7_simulations, one per case. The tracker is filled in from them, so:
esm-hist, spelt as in the tracker;r1i1p1f1;completed: add this label when the run has finished;test: add this label to a case that is not a CMIP7 run, to leave it out;run-qa, cmip7prep-qa, cmor4cmip7-qa and esgf, each added when its step is done;### Run script https://github.com/NorESMhub/noresm_cmip7_simulations/blob/CMIP7_Runscripts/scripts/piControl/011.n1850GHGGaxg.LM.b28.20261102.sh ### Continues #2 ### cmip7prep output root /nird/datalake/NS9560K/noresm3/cases/n1850GHGGaxg.LM.nor30b28.011.20261102.cmor ### cmor4cmip7 output root /nird/datapeak/NS9034K/CMIP7
The progress script reads the two output roots for the cmip7prep and cmor4cmip7 columns; Run script and Continues are for readers.
Once the progress script has read an issue, the run shows it in the Issues column. The experiment label and the case name's resolution pick the run; the variant label picks the member.
### Continues in its description, e.g. #2. The tracker reads the two as one simulation and takes its progress from the later model date, as with #2 and #11;r2i1p1f1. The run's years done are the mean over its members.Push the case's run script straight to its experiment's directory under scripts/ on the CMIP7_Runscripts branch; this needs write access to the repository.
scripts/<experiment>/, named after the issue's experiment label, e.g. scripts/piControl/. Every experiment label has one; a new label needs its own directory, with an empty .gitkeep file so that git keeps it while it is empty;issue.compset.resolution.beta.date.sh, each part copied from the case name, e.g. 011.n1850GHGGaxg.LM.b28.20261102.sh for n1850GHGGaxg.LM.nor30b28.011.20261102;git switch CMIP7_Runscripts and git pull, copy the script into its experiment's directory under its name, then git add, git commit and git push. Without a clone, open the experiment's directory under scripts/ on GitHub, use Add file → Upload files and choose Commit directly to the CMIP7_Runscripts branch;Run script for #11, with the case's issue number. GitHub then shows the commit on the issue. Don't write Closes #11 or Fixes #11: either closes the issue;### Run script, e.g. https://github.com/NorESMhub/noresm_cmip7_simulations/blob/CMIP7_Runscripts/scripts/piControl/011.n1850GHGGaxg.LM.b28.20261102.sh.The QA column depends on the label run-qa: it shows ✓ once the case's issue has it, after the next run of the progress script. Add the label when the run's QA is done.
Create and build the case. On Olivia and Betzy, cases go in /cluster/projects/nn9560k/$USER, each in a directory named after the case: /cluster/projects/nn9560k/$USER/<case>.
Go through the QA checklist, then add the label run-qa to the issue.
The progress script reads the run's Status and Progress on NIRD.
Set the run's priority and coordinate it with the other runs. Copy the output to NIRD by hand with rsync while the run is going. The progress script reads the years done from the atmosphere history files copied there, and the tracker shows them in the Progress column and sets the Status to In progress. To set it to Completed, add the completed label to its issue.
Once the simulation has finished, open an issue in NorESMhub/CMIP7_CMOR-Publish from its template, which is like the CMIP6 one, and label it cmorization. The repository's other labels are publication, archive, cmor_bug, publication_bug and retract.
As each tool starts, add its output root to the description of the case's issue in noresm_cmip7_simulations, under a heading of its own:
### cmip7prep output root /nird/datalake/NS9560K/noresm3/cases/<case>.cmor ### cmor4cmip7 output root /nird/datapeak/NS9034K/CMIP7
The progress script reads each tool's progress there, and the tracker shows the roots when you hover the cmip7prep or cmor4cmip7 column.
The CMORized output goes in /nird/datalake/NS9560K/noresm3/cases/$CASE.cmor for now, and will later go in /nird/datapeak/NS9034K/CMIP7 with the cmor4cmip7 output. The progress script reads the completed_steps_*.json files cmip7-prep writes there, and the tracker shows the years CMORized so far, e.g. 1–50. Without a cmip7prep output root in the issue, the script looks in the case's .cmor directory.
The QA column after cmip7prep depends on the label cmip7prep-qa: it shows ✓ once the case's issue has it, after the next run of the progress script. Add the label when the cmip7-prep output has been validated.
The CMORized output goes in /nird/datapeak/NS9034K/CMIP7. The first 100 years of piControl's ocean are being CMORized there now. The progress script reads the time ranges in the names of the case's files under the issue's cmor4cmip7 output root, e.g. _000101-001012.nc, and the tracker shows the years every variable has, e.g. 1–10. The case's files are the ones whose names have its experiment and variant, e.g. _piControl_r1i1p1f1_, so the root can hold other runs too.
The QA column after cmor4cmip7 depends on the label cmor4cmip7-qa: it shows ✓ once the case's issue has it, after the next run of the progress script. Add the label when the cmor4cmip7 output has been QA'd.
cmip7-prep and cmor4cmip7 lay out their output differently. That doesn't matter for publication: esg-prep links both into the structure ESGF needs. The CMORization and publication workflow, and the esg-prep command, will be added here as they are settled.
The ESGF column depends on the label esgf: it shows ✓ once the case's issue has it, after the next run of the progress script. Add the label when the data is published.
The runs with a case issue, with the cost and throughput measured from their cases' timing files on each machine, Olivia in green and Betzy in orange: the mean over their jobs, each weighted by the years it simulated. Click a run's job count to plot its SYPD and cost job by job. A run with no timing files on a machine yet shows its configuration's value in grey, and is costed with it.
| Run | Machine | Cost / sim-yr | SYPD | Jobs |
|---|
Each run's core-hours and SYPD are on the machine it runs on: Betzy for a run whose timing files say so, Olivia otherwise. Click a MIP to open or close its runs. Edit Members, Years each and Configuration here, or untick a run to take it out of the plan, to see what it would cost. A run with timing files of its own is costed with them; any other run with its configuration's value, the mean over that configuration's runs that have timing files, or an earlier timing if none has. Changes are not saved; the plan itself is set when the page is built. Unticked runs are listed at the bottom. It shows the full planned cost; progress is tracked on the Tracker page. Core-hours are members × years × cost per simulated year. Days per member is how long one member takes on its own.
Hover a run for details · click a run to trace its dependency chain · click empty space to clear.
Total compute cost (core-hr), grouped by the MIP each simulation belongs to — runs without a MIP tag are grouped into DECK.
Total compute cost (core-hr), grouped by each simulation's priority level.