The example workflow ran start to finish and every result was correct. A second run was made to fail on purpose; it stopped at the check that the coordinator can serve (the readiness gate), before any worker started.
You need
Access to one compute node through Slurm. The test used one node on a shared partition.
Apptainer on the compute nodes.
A private folder for the job that you can write to (job-scoped scratch).
Depends on your center
Your account and partition names. You supply them when you submit the job.
How Apptainer is made available: on the default command path, or through a module your center provides.
Which scratch location the job uses. Centers provide it in different ways.
The coordinator listens only on loopback (127.0.0.1); reaching it from beyond the node needs access your center approves.
Whether each worker can run as its own job step (a program the scheduler launches and tracks inside your allocation) on a shared node.
Whether you can rebuild the container image yourself. On the newer Apptainer used for the latest test, the release’s image build script could not run without extra privileges, so the tested image is the earlier build with the same fingerprint (digest).
Milestone 2 extends the Milestone 1 baseline toward portability across schedulers and runtimes, adds an orientation tour, documents the adaptation seams that let adopters reuse the reference workflow for their own applications, and publishes the guide through talks and posters.
The tour is additive to the fellowship statement of work: it is not a SOW-listed deliverable. It is tracked here as M2-MODULE-0 for transparency, and it answers the program-review suggestion quoted below.
Modules 4 and 5 are the SOW “portability modules” deliverable (SOW topics 2 and 3). Module 3 is supporting material for that deliverable, not a SOW-listed deliverable itself.
Talks and posters are linked from Talks and papers. This site links to them where they are hosted and hosts none of their files, except the I-GUIDE Forum 2026 poster, which has its own event page.
Planned
Module 5: reuse one CPU software layer across GPU variants (SOW topic 3, runtime portability). Draft due 2026-11-13.
Module 4: Slurm and PBS-family launch templates (SOW topic 2). Scope to be determined.
Feedback traceability
The Milestone 1 program review (2026-08-14) made one suggestion and asked four questions. They are quoted exactly.
I think the site could use a site-map or a “module 0” that gives users a baseline of who the audience is and how they should progress through the modules/site as a whole. It would be helpful to know what assumptions and pre-existing skills a learner should have.
What does the “workflow source” do? How would a user modify it to run their own application? It seems that the workflow includes results verification, is this something the user would expect to see for their own application? Are the various json files (such as results.json) intended for humans or for other tools to parse?
Source: Milestone 1 program review, 2026-08-14. Where each part is answered:
A home page written for newcomers: a two-environment figure, three doors (understand the model, translate a Compose file, evaluate and adopt), the four concepts of the big idea, and a Compose-to-sbatch crosswalk.
A six-step timeline of one allocation from start to finish, on the five-minute tour and in Modules 1–2.
A five-minute tour of the model, a Compose-to-Slurm translation module, and an evaluation guide for research software engineers and center staff, including what has not been tested.
A Talks and papers page that links to each presentation where it is hosted.
An evidence badge and panel on pages that rely on a test, each linking to the dated test record. Material not run on a cluster is labelled “Shim-tested” (run off-cluster against test fixtures) or “Designed, not run”.
A new visual system: self-hosted fonts, and light and dark themes that follow your system setting. One toggle switches the theme and remembers your choice.
Changed
Module 2 explains which parts of the workflow package to keep, which to replace, and how its result files are meant to be read.
The getting-started path, the glossary and the navigation follow the same plain-language-first order as the home page.
Each test record opens with a plain-language summary of what was tested.
Module 2 was re-tested in October 2026. The image was reused, not rebuilt: it has the same digest as the July build, because this release’s script cannot rebuild it without privileges on the newer Apptainer there. The dated test record gives the date, the system and the versions, and the July record is kept.
Deprecated
None in this release.
Corrected
The v0.2.0 workflow README now points to the dated validation record instead of describing the workflow as not run.
Diagnostic identifiers are consistent between the diagnostics page and the workflow.
The test record now lists the deliberate failure run next to the successful run.
The README fingerprints shown on the July test record and on the scheduler-as-orchestrator page now match the files at the v0.1.0 tag they link to.