Skip to content

Commit 5feeaa4

Browse files
andyclaude
andy
and
claude
committed
Add Quantum ESPRESSO code registration, phase 1 (scf only)
Implements phase 1 of docs/QE_ROADMAP.md: registration skeleton and calculation='scf'. No relax, vc-relax, MD or phonons, and deliberately no Vibration runtype -- ph.x needs pw.x -> ph.x -> dynmat.x, which breaks ECCE's one-code-one-path model, so it is left out exactly as MOPAC shipped without a TS runtype. No C++ changes. Verified by generating decks and running them, not by inspection: all four fixture inputs were produced by ai.qe from real .param/.frag pairs and run through the installed pw.x (Debian 6.7) to JOB DONE -- bulk Si (fixed occupations, forces+stress), water in a box (Gamma, two species), fcc Al (smearing, the metal path), and triplet O2 (nspin=2, converging to exactly 2.00 Bohr magneton). pw.x treats an unrecognised namelist variable as fatal, so nothing passed silently. gensub was driven end to end for both the serial and mpirun forms. qe.desc declares six parse types and all six fire on the fixtures: VERSION, TE, EWVEC, DELTAE, EGRADVEC, CPUSEC/ETIME. 865 -> 963 checks. These fixtures test generation AND parsing as one pipeline, which is not true of any other code's fixtures in this suite. Pseudopotentials work differently from the roadmap's sketch, for a real reason. A per-element combo in the dialog is not implementable: codereg dialogs are standalone processes whose entire input is globals.py's fixed argv, so nothing tells them which elements the structure contains. The per-element resolution therefore lives in ai.qe, which reads the .frag and scans /usr/share/espresso/pseudo (verified: 103 files, 103 elements, no collisions, coping with all four packaged naming shapes). The dialog contributes pseudo_dir, a type preference applied with fallback, and a live re-scanned status line. No filename is ever typed, selection is driven by what is on disk, and a missing element is refused by name -- the three actual requirements. That dialogs are never told the fragment composition is a general gap worth recording; it blocks any future per-element UI. Two real bugs found while building it: - ai.<code>'s template engine silently swallows die(). modifyInputFile resolves each ##tag## through eval, so a die inside a resolver is caught, the tag's line vanishes and the script exits 0 with a quietly incomplete deck. Validation moved into the main flow. ai.mopac has the same latent shape and should get its own issue. - A bare top-level hash assignment placed after the main flow never runs, so every atomic mass silently came out as the 1.0 placeholder. Also verified against the binary: a "!" comment is fine inside a namelist but fatal inside ATOMIC_SPECIES. Separately, no C++ in this tree reads the .edml comment/commentstring attributes at all, so they are dead everywhere. NOT verified: nothing was run in the GUI. The New-Calculation menu entry, save-to-dataserver, the CalcEd code-switch buttons and property display are all untested, and testing the httpd.conf.ecce change needs ecce-dataserver-stop first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 parent 99ab2ec commit 5feeaa4

29 files changed

Lines changed: 4251 additions & 0 deletions

‎data/client/cap/QuantumESPRESSO.edml‎

Lines changed: 164 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,164 @@
1+
<?xml version="1.0" encoding="utf-8" ?>
2+
3+
<!--
4+
Quantum ESPRESSO (pw.x) code registration, PHASE 1 reduced-scope
5+
first cut. See docs/QE_ROADMAP.md for the full plan; this file
6+
implements its section 5 "Phase 1". Modeled on MOPAC.edml (issue
7+
#86) and ORCA.edml (issue #38) as the two most recent worked
8+
examples, and on MetaDyn.edml as the only existing plane-wave-only
9+
code registration.
10+
11+
QE IS A PLANE-WAVE code, which makes this file structurally like the
12+
nwpw path rather than like any Gaussian-basis code:
13+
14+
* There is NO <GaussianBasisSetRules> block and NO
15+
<BasisTranslationScript>. A plane-wave basis is defined by a
16+
kinetic-energy cutoff (ecutwfc), which is a field in the Theory
17+
Details dialog, not a library selection. The single <Theory>
18+
below carries needsBasis="false", the pre-existing ECCE
19+
mechanism for this (NWChem.edml's category="NWPW" theories and
20+
MOPAC.edml's category="SE" theories both use it):
21+
CalcEd::updateBasisWidgets() greys out the Basis Set Tool, and
22+
ESInputController's write_gbsconfig()/write_setup() skip the
23+
.basis file and the BasisSet.Coordinates key entirely, so ai.qe
24+
is never handed a -b argument. CodeFactory::getBasisCodes()
25+
likewise filters QE out of the Basis Set Tool's code list
26+
because <GaussianBasisSetRules> is absent. No C++ change was
27+
needed for any of this.
28+
29+
* PERIODICITY IS MANDATORY, unlike for every other registered
30+
code. pw.x cannot run without a unit cell, so a structure with
31+
no LatticeDef cannot produce a valid deck. ai.qe refuses
32+
loudly (naming the Builder's "Periodic Builder" tool panel)
33+
rather than emitting a deck pw.x would reject with a cryptic
34+
namelist error. The cell comes from the fragment ONLY, via the
35+
.frag's lattice_vectors: section; nwpw's second, unsynchronized
36+
set of cell fields in its own theory dialog is deliberately not
37+
repeated here.
38+
39+
* There is no <Importer> (a QuantumESPRESSO.expt post-hoc output
40+
importer for externally-run jobs is not written yet), so QE
41+
simply does not appear in CodeFactory::getImportCodes(), which
42+
is correct behavior rather than an error. ORCA.edml declares an
43+
<Importer>ORCA.expt</Importer> that does not exist on disk;
44+
that is not copied here.
45+
46+
THE INPUT FILE NAME IS FREE, unlike MOPAC's. pw.x takes its deck
47+
with "-in <file>" and writes its report to stdout, so it has no
48+
opinion about either name and the distinctive extensions the
49+
new-code checklist calls for are simply available: .pwin / .pwout,
50+
with matching AddType lines in
51+
packaging/dataserver/httpd.conf.ecce. Generic .in/.out would fall
52+
through to Apache's DefaultType text/plain and break the
53+
mimetype-filtered primary-input lookup in a way that looks exactly
54+
like a save failure.
55+
56+
NO VIBRATION OR GEOVIB RUNTYPE, and no relax/vc-relax/nscf/bands,
57+
deliberately. Vibrational frequencies in QE need a THREE-executable
58+
chain, pw.x then ph.x then dynmat.x, sharing prefix/outdir: that is
59+
the one part of QE that does not fit ECCE's "one calculation, one
60+
input, one binary, one output" model (see docs/QE_ROADMAP.md
61+
section 3.2), and the Vibrational Frequencies panel it would feed is
62+
itself currently broken under wx3.2/GTK3 (issue #81). Shipping
63+
without it has precedent: MOPAC shipped with no transition-state
64+
runtype. The other calculation modes are phases 3 to 5 of the
65+
roadmap.
66+
67+
Verified end to end against the real installed Quantum ESPRESSO 6.7
68+
(Debian quantum-espresso 6.7-3+b1, /usr/bin/pw.x) on 2026-09-21:
69+
decks generated by ai.qe from real .param/.frag pairs were run to
70+
completion ("JOB DONE.") for bulk silicon (Monkhorst-Pack grid,
71+
fixed occupations), water in a box (gamma point, two species), fcc
72+
aluminium (metallic smearing) and triplet O2 (nspin = 2,
73+
tot_magnetization). pw.x echoes any unrecognized namelist variable
74+
as a fatal error, so no emitted keyword can pass silently.
75+
-->
76+
77+
<appdescriptor>
78+
79+
<!--
80+
Enables Geometry and Partial Charge sub dialogs if runtype is
81+
appropriate. QE does support fixed atoms (the if_pos flags on
82+
ATOMIC_POSITIONS) but only for a relax run, which phase 1 does not
83+
offer, and ai.qe does not write them, so this is left false rather
84+
than advertising a capability the input generator drops.
85+
-->
86+
<SupportsConstraints>false</SupportsConstraints>
87+
88+
89+
<!-- One plane-wave theory, one runtype. "PW" is the plane-wave
90+
pseudopotential method itself; the exchange-correlation functional
91+
is NOT part of the theory name because for a pseudopotential code
92+
it is a property of the pseudopotentials (the packaged Debian SSSP
93+
library is entirely PBE). The Theory Details dialog offers an
94+
input_dft override for the rare case where that is wanted.
95+
96+
Energy maps to calculation='scf'. Forces and the stress tensor
97+
are available on an scf run (tprnfor / tstress) and are exposed as
98+
Runtype Details checkboxes, so a separate Gradient runtype would
99+
add nothing in phase 1. -->
100+
<Editor theorydialog="qetheory.py" runtypedialog="qeruntype.py">
101+
<Theory category="PW" name="PW" needsBasis="false">
102+
<runtype>Energy</runtype>
103+
</Theory>
104+
105+
<TheorySummary topLabel="Plane Waves-">
106+
<item key="ES.Theory.PW.EcutWfc" label="Wavefn. Cutoff (Ry)"></item>
107+
</TheorySummary>
108+
<TheorySummary>
109+
<item key="ES.Theory.PW.Occupations" label="Occupations"></item>
110+
</TheorySummary>
111+
<TheorySummary>
112+
<item key="ES.Theory.PW.KPointScheme" label="k-points"></item>
113+
</TheorySummary>
114+
<TheorySummary>
115+
<item key="ES.Theory.PW.ConvergenceEnergy" label="SCF Convergence"></item>
116+
</TheorySummary>
117+
118+
<RuntypeSummary topLabel="Properties-">
119+
<item key="ES.Runtype.PW.PrintForces" label="Forces"></item>
120+
</RuntypeSummary>
121+
<RuntypeSummary>
122+
<item key="ES.Runtype.PW.PrintStress" label="Stress"></item>
123+
</RuntypeSummary>
124+
</Editor>
125+
126+
127+
<!-- Raw File Naming Conventions. See the header comment for why the
128+
extensions are free to be distinctive here (pw.x names neither
129+
file itself). verifypattern is "Program PWSCF" and deliberately
130+
carries NO version number: the banner reads
131+
"Program PWSCF v.6.7MaX starts on ...", so anchoring on the
132+
version would break on every QE upgrade. MOPAC could get away
133+
with "MOPAC v" only because there the name and the "v" are
134+
adjacent.
135+
136+
comment/commentstring are declared for consistency with the other
137+
descriptors, but note two things: no C++ in this tree reads either
138+
attribute (JCode.C parses only type, mimetype and verifypattern),
139+
and QE accepts "!" comments inside a NAMELIST but NOT inside a
140+
card such as ATOMIC_SPECIES, where a "!" line is a fatal
141+
card_atomic_species read error (verified against the real 6.7
142+
binary). -->
143+
<DataFiles>
144+
<Input type="primary" mimetype="chemical/x-qe-input" comment="true" commentstring="!">qe.pwin</Input>
145+
<Output type="primary" mimetype="chemical/x-qe-output">qe.pwout</Output>
146+
<Output type="parse" verifypattern="Program PWSCF" mimetype="chemical/x-qe-output">qe.pwout</Output>
147+
</DataFiles>
148+
149+
<!-- Names of files required for code integration. These files are
150+
assumed to be in the ecce path as managed by the ecce_env script.
151+
All of these exist under scripts/parsers. <LaunchPreprocessor> is
152+
required unconditionally: Launch::postProcessInput() shells out to
153+
JCode::launchPPScript() with no empty-string check, so a code
154+
without one fails launch with a bare "-p postParams" command name.
155+
QE genuinely needs one anyway, to rewrite &CONTROL outdir to the
156+
scratch directory Launch actually allocated. -->
157+
<IntegrationFiles>
158+
<Template>qe.tpl</Template>
159+
<InputGenerator>ai.qe</InputGenerator>
160+
<ParseSpecification>qe.desc</ParseSpecification>
161+
<LaunchPreprocessor>qe.launchpp</LaunchPreprocessor>
162+
</IntegrationFiles>
163+
164+
</appdescriptor>

0 commit comments

Comments
 (0)