npc is the operator entrypoint for a staged workflow that separates:
- phonon frontend generation (
stage1) - MLFF screening (
stage2) - QE top-5 recheck (
stage3)
The repository is designed for structured production runs. User input lives outside the repository. Runtime contracts and stage outputs live under a run root created by the workflow itself.
For the current call-path view, see ARCHITECTURE.md.
The current stable code line already includes the following operator-facing capabilities:
- a single entrypoint,
npc, forstage1,stage2,stage3, status, and cross-machine handoff - explicit runtime contracts under
contracts/so that later stages can reuse earlier results without reconstructing state manually - four
stage2model presets:gptff_v1gptff_v2chgnetmattersim_v1_5m
- a default
stage2model preset ofgptff_v2 stage3prepare/reuse/submit behavior with separateprepare_onlyandsubmit_collectmodes- comparison outputs that keep local
stage2and remote/referencestage3results on the same schema for downstream analysis
The repository therefore serves two roles at once:
- it runs the production workflow through
npc - it also ships a small set of offline analysis scripts under
reports/for benchmark and comparison work
The repository is easier to read if it is treated as a small set of distinct subsystems rather than one large workflow bundle.
start_release.py- thin user-facing launcher behind
npc - parses high-level stage options and forwards them into the staged runtime
- thin user-facing launcher behind
server_highthroughput_workflow/- runtime orchestration
- owns stage dispatch, run-root layout, handoff import/export, status, and stage-to-stage contract flow
qe_phonon_stage1_server_bundle/stage1phonon frontend and its supporting screening/pair-selection tools
mlff_modepair_workflow/stage2frozen-phonon evaluation, pair ranking, and reference comparison- owns backend calculators for GPTFF, CHGNet, and MatterSim
qe_modepair_handoff_workflow/stage3QE preparation, submission, and collection for selected top pairs
reports/- offline scripts for extracting benchmark tables and generating comparison figures
- these scripts are tools, not part of the main
npcexecution path
The three workflow stages are intentionally asymmetric.
stage1- produces phonon-derived candidate mode pairs and a
stage1contract - is the most environment-sensitive stage because the QE phonon frontend must run reliably on the host
- produces phonon-derived candidate mode pairs and a
stage2- evaluates the candidate mode-pair grid with a selected MLFF backend
- produces ranked pairs and comparison-friendly JSON/CSV outputs
stage3- prepares and optionally submits QE rechecks for the top-ranked pairs
- is designed to consume
stage2outputs without changing the ranking schema
This separation is deliberate. stage2 and stage3 are meant to be compared,
not just chained.
This package is intended for workflows in which:
- the structure is supplied as
structure.cif - pseudopotentials are supplied explicitly by the operator
stage1,stage2, andstage3may run on different machines- cross-machine continuation is handled by explicit handoff bundles
The package does not hide cross-machine continuation. It formalizes it.
Each system must be prepared under an external input root:
<input_root>/
<system_id>/
structure.cif
system.json
pseudos/
*.UPF
Minimal required files:
structure.cifsystem.jsonpseudos/*.UPF
Example input tree:
Minimal system.json schema:
{
"system_id": "wse2",
"formula": "WSe2",
"workflow_family": "tmd_monolayer_hex",
"preferred_pseudos": {
"W": "W.pz-spn-rrkjus_psl.1.0.0.UPF",
"Se": "Se.pz-n-rrkjus_psl.0.2.UPF"
},
"already_relaxed": false,
"notes": "Optional free-form note"
}Each run creates a runtime tree under a runs root:
.../Nonlinear-Phonon-Calculation-runs/
<system_id>/
<run_tag>/
contracts/
logs/
stage1/
stage2/
stage3/
Key principle:
- user input stays in the external input tree
- workflow state stays in the runtime tree
- internal contracts are runtime artifacts, not user-authored inputs
From the repository root:
./install.shRepository-local execution:
./npc --helpIf the user install location is already on PATH, the installed entrypoint is
equivalent:
npc --helpCompatibility entrypoints are also provided:
./tui --help
python3 start_release.py --helpThis package does not assume a site-specific environment name. The required
interface is a set of executables and Python modules available in the shell
that launches npc.
One-command stage environment scripts are provided under:
ops/setup_stage1_env.shops/setup_stage2_env.shops/setup_stage3_env.sh
These scripts configure the Python side of the workflow in the current shell environment and then validate stage-specific external requirements.
python3python3 -m pipgit- a successful
./install.sh
stage1- run
bash ops/setup_stage1_env.sh pw.xph.xq2r.xmatdyn.xsbatchsqueue
- run
stage2- run
bash ops/setup_stage2_env.sh - importable Python modules:
gptffchgnettorchphonopypymatgen
- run
stage3- run
bash ops/setup_stage3_env.sh - QE executables on
PATH - if
submit_collectis used:sbatchsqueue- a Slurm runtime suitable for batch QE work
- run
stage1depends on Slurm in the current implementation. It is not a pure local frontend runner.stage1is the most demanding stage with respect to QE phonon frontend stability. Run it on a host already known to executeph.xreliably.stage2is primarily a Python materials-stack workload and is comparatively easy to migrate oncestage1has produced a valid contract.stage2supports four model presets:gptff_v1gptff_v2chgnetmattersim_v1_5m
- The default
stage2model preset isgptff_v2. stage3supports two modes:prepare_onlysubmit_collect
stage3 --qe-mode prepare_onlycan be prepared without Slurm, butsubmit_collectrequires Slurm.
If your site uses Conda, modules, or environment scripts, activate that
environment first and only then launch npc. This README deliberately does not
prescribe a site-local activation command.
Stage 1 host:
bash ops/setup_stage1_env.shStage 2 host:
GPTFF_SOURCE=/path/to/GPTFF bash ops/setup_stage2_env.shStage 3 host for queue submission:
bash ops/setup_stage3_env.shStage 3 host for preparation only:
STAGE3_MODE=prepare_only bash ops/setup_stage3_env.sh./npc --input-root /path/to/Nonlinear-Phonon-Calculation-inputs --system wse2./npc \
--input-root /path/to/Nonlinear-Phonon-Calculation-inputs \
--system wse2 \
--stage stage1 \
--qe-relax yes./npc \
--input-root /path/to/Nonlinear-Phonon-Calculation-inputs \
--system wse2 \
--stage stage2This command uses gptff_v2 by default.
./npc \
--input-root /path/to/Nonlinear-Phonon-Calculation-inputs \
--system wse2 \
--stage stage3 \
--qe-mode prepare_onlyBy default, stage3 reads the stage1 autotune result and uses the
system-specific pes.balanced profile. If the autotune result is missing, it
falls back to the static static_balanced preset. The historical names
pes_balanced and pes_fast remain accepted only as legacy static aliases.
Available presets:
gptff_v1gptff_v2chgnetmattersim_v1_5m
Examples:
./npc \
--input-root /path/to/Nonlinear-Phonon-Calculation-inputs \
--system wse2 \
--stage stage2 \
--stage2-model gptff_v1./npc \
--input-root /path/to/Nonlinear-Phonon-Calculation-inputs \
--system wse2 \
--stage stage2 \
--stage2-model chgnet./npc \
--input-root /path/to/Nonlinear-Phonon-Calculation-inputs \
--system wse2 \
--stage stage2 \
--stage2-model mattersim_v1_5m./npc \
--input-root /path/to/Nonlinear-Phonon-Calculation-inputs \
--system wse2 \
--stage stage3./npc \
--input-root /path/to/Nonlinear-Phonon-Calculation-inputs \
--system wse2 \
--stage stage3 \
--qe-mode prepare_only./npc \
--run-root /path/to/run_root \
--stage stage3 \
--qe-mode submit_collectLatest detected run:
./npc --statusSpecific system or run root:
./npc --input-root /path/to/Nonlinear-Phonon-Calculation-inputs --system wse2 --status
./npc --run-root /path/to/Nonlinear-Phonon-Calculation-runs/wse2/wse2_20260331_235959 --statusAfter stage1:
./npc --handoff-export stage1 --run-root /path/to/run_root --output /tmp/wse2_stage1_handoff.tar.gzAfter stage2:
./npc --handoff-export stage2 --run-root /path/to/run_root --output /tmp/wse2_stage2_handoff.tar.gz./npc --handoff-import --bundle /tmp/wse2_stage1_handoff.tar.gz --run-root /path/to/new_run_root./npc \
--input-root /path/to/Nonlinear-Phonon-Calculation-inputs \
--system wse2 \
--stage tune \
--qe-relax noInput:
structure.cifsystem.jsonpseudos/*.UPF
Actions:
- generate internal QE inputs
- optionally run QE relax
- run the QE phonon frontend
- extract screened eigenvectors
- select modes
- generate mode pairs
- write
contracts/stage1.manifest.json
Primary outputs:
stage1/outputs/mode_pairs.selected.jsoncontracts/stage1.manifest.json
tune is a family-aware convergence stage. It reads workflow_family from
system.json, runs the configured scan, and writes reusable profile selections
into the stage1 runtime bundle.
Input:
contracts/stage1.manifest.json
Actions:
- load the imported or locally generated stage1 contract
- run stage2 MLFF screening with the selected model preset
- rank candidate mode pairs
- write
contracts/stage2.manifest.json
Primary outputs:
stage2/outputs/<backend>/screening/pair_ranking.csvstage2/outputs/<backend>/screening/single_backend_ranking.jsoncontracts/stage2.manifest.json
Input:
contracts/stage2.manifest.json
Actions:
- select the top-5 pairs
- prepare QE recheck jobs
- optionally submit and collect them
- write
contracts/stage3.manifest.json
Behavior:
- if a QE batch has already been prepared, rerunning
npcreuses it - if final QE collection already exists, rerunning
npcreuses the completed result
Primary outputs:
stage3/qe/<backend>/run_manifest.jsoncontracts/stage3.manifest.jsonstage3/qe/<backend>/results/qe_ranking.jsonwhen collection finishes
./npc --status reports:
- discovered stage contracts
stage1handoff summarystage2ranking summarystage3QE run root- prepared job count
- submission progress
- final QE state
- resume mode
For normal operation, --status should be the first inspection command. Manual
inspection of lower-level runtime files should only be needed for debugging.
Recommended operator sequence:
- run
stage1on a machine with a stable QE phonon frontend - export a
stage1handoff bundle - import it on a machine prepared for
stage2 - run
stage2 - either continue in place or export a
stage2handoff bundle - import on the machine intended for
stage3 - run
stage3
The handoff bundle preserves relative runtime paths by rewriting them against
the imported run root. Cross-machine continuation should therefore use
--handoff-export and --handoff-import, not manual directory copying.
flowchart TB
A["External input tree\nstructure.cif + pseudos + system.json"] --> B["npc / tui\noperator entrypoint"]
B --> C["Create or reuse run root"]
C --> D["stage1\nQE phonon frontend"]
D --> E["contracts/stage1.manifest.json"]
E --> F["stage2\nMLFF screening\n(default: GPTFF v2)"]
F --> G["contracts/stage2.manifest.json"]
G --> H["stage3\nQE top5 recheck"]
H --> I["contracts/stage3.manifest.json"]
B --> J["Read-only status\n./npc --status"]
B --> K["Cross-machine handoff\nexport / import bundle"]
E --> K
G --> K
nonlinear_phonon_calculation/- CLI entrypoints and input discovery
server_highthroughput_workflow/- orchestration, runtime preparation, manifests, and stage2/3 helpers
qe_phonon_stage1_server_bundle/- stage1 phonon frontend and convergence tooling
mlff_modepair_workflow/- stage2 MLFF screening logic for GPTFF and CHGNet backends
qe_modepair_handoff_workflow/- stage3 QE preparation and collection helpers
examples/wse2_input_example/- user-facing input example