rdeboer1/rmfit-campaign

Der rmfit-Prozess

rmfit (/groups/rdeboer1/user/rdeboer1/R-matrix/rmfit/, README dort) macht das, was ein Evaluator von Hand macht – polieren, Interferenzvorzeichen umdrehen, Ebenen hinzufügen oder entfernen, verdächtige Datensätze ausschalten – als fortsetzbare Schritte, die ein Skript auf einem Cluster-Knoten ausführt und die eine neue Sitzung aus STATUS.md aufnehmen kann. Es ist nicht als Paket installiert:

export PYTHONPATH=/groups/rdeboer1/user/rdeboer1/R-matrix
python3 -m rmfit.cli <campaign_dir> <command> [options]

Lesen Sie diese Datei vor dem ersten Befehl für eine neue Reaktion vollständig durch; zur Fortsetzung einer Kampagne genügen „Den Status lesen“ und „Die Schleife“. Verfeinerungen werden am Ende im Protokoll festgehalten.

1. Den Status lesen, nie neu berechnen

Ein Kampagnenverzeichnis enthält alles, was eine neue Sitzung benötigt:

• STATUS.md – das beste verifizierte Ziel pro Struktur, aktuelle Runden und Protokollzeilen. Mit status neu generieren; status --json für eine kompakte Ausgabe.
• readme – das Laborbuch (rmfit fügt einen Absatz pro Runde hinzu; eigene Einträge mit log "..." hinzufügen). Archivkonvention: Lesen, bevor Sie etwas anfassen.
• campaign.log – jede Zeile, die der Treiber gedruckt hat; rmfit_sge.log / rmfit_*.log – Cluster-Job-Protokolle.
• ledger.sqlite + candidates/*.npz – jeder Kandidatenvektor und -score. Der Amtsinhaber ist der beste Kandidat mit einem verified-Score (eine neue Einzelsitzungsauswertung des vollständigen Modells). Shard-Zahlen ordnen; verifizierte Zahlen werden gemeldet.
• campaign.json – Basismodell, Engine-Flags, Shard-Anzahl, Grenzwerte-Policy, Suchkonfiguration.
• <reaction>.azr + .sav – der GUI-prüfbare Export des Amtsinhabers.
• variants/ – Shard-Dateien, Fenstermodelle, Dateien mit/ohne Level (wegwerfbar).

Zuerst qstat -u $USER: ein Kampagnenbefehl pro Verzeichnis (sie teilen sich das Ledger und variants/). Der Login-Knoten ist für status, report, log, export, kurze Tests (<= 6 Arbeiter, <= 30 min). Alles andere läuft als Job.

2. Eine Kampagne für eine neue Reaktion starten

Voraussetzungen (diese im Reaktions-Fit-Verzeichnis durchführen, nicht in der Kampagne):

1. Eine .azr, die sich in der GUI öffnet, mit data/, einem output/-Verzeichnis und einem readme. Kennen Sie die CLI-Modus-Flags, die diese Reaktion verwendet (--use-brune, --ignore-externals, --no-long-wavelength, ...): sie sind nicht in der .azr, sie variieren pro Reaktion (~/R-matrix/CLAUDE.md), und rmfit benötigt sie als --flags JSON.
2. Reproduzieren Sie den letzten abgeschlossenen Fit, bevor Sie darauf aufbauen: laden Sie dessen param.sav namentlich (pyazr), bestätigen Sie, dass das Ziel mit chiSquared.out übereinstimmt (chi2 + Norm-Strafterm), dann backen Sie es in eine saubere Datei (rmfit.engine.bake) und überprüfen Sie es mit dem CLI im Modus 1 mit einer leeren externen Datei. Vertrauen Sie nie einem Bake, das mit der .sav als externe Datei „verifiziert“ wurde (das überschreibt <levels>), und verwenden Sie niemals Parameter aus einem laufenden oder abgestürzten Fit – nur den letzten abgeschlossenen. Entfernen Sie inaktive Levelzeilen.
3. Fügen Sie neue Datensätze in die gebackene Datei ein (AzrModel.add_data_segment), begrenzt auf den Energiebereich, den das Level-Schema abdeckt (set_segment_energy_range), mit freien Normalisierungen und einem systematischen Fehler, der das Papier widerspiegelt. Sehen Sie sich jede neue Datei an: ein einziger negativer oder spike-Querschnitt kann das Ziel dominieren.
4. Halten Sie all dies im readme des Reaktionsverzeichnisses fest.

Erste Fits: Startparameter vor jedem globalen Fit aufbauen (DeBoer, 2026-10-25 – SPÄTER NEU BEWERTEN)

Provisorisch. Dies ist DeBoers allgemeiner Vorschlag, niedergeschrieben, bevor er vollständig getestet wurde. Bewerten Sie ihn neu, sobald 10B+α (die erste Reaktion, die ihn verwendet, 10B+a/10-25-26_Rmatrix_Claude) einen echten Fit hat: notieren Sie, was funktioniert hat und was nicht, und ändern oder streichen Sie das Verfahren entsprechend.

DeBoer: "Fixieren Sie die Normen eines repräsentativen Datensatzes, lassen Sie aber die anderen variieren. Dies liefert zunächst eine festere Skala für die Querschnitte, erlaubt aber dennoch, dass Datensätze mit inkonsistenten Normen, aber konsistenten Formen den Fit nicht behindern. In unserem Fall, da wir Daten in jedem Kanal haben, schlage ich vor, unsere Daten zunächst zu fixieren und die anderen variieren zu lassen. Außerdem sollten wir sicherstellen, dass wir die niedrigsten l-Kanäle für jedes Teilchenpaar variieren lassen, indem wir jedem Level einen kleinen Wert ungleich Null für diesen Kanal geben, auch wenn die Literatur keinen Zweig in diesen Kanal angibt. Ich würde auch vorschlagen, bei niedriger Energie zu beginnen und einige Polierungen auf einem Level nach der anderen durchzuführen, um zu sehen, wie gut es die Daten abgleichen kann. Dann zurückkommen und versuchen, Levels hinzuzufügen, wo Resonanzen deutlich vorhanden sind, die in Energie und/oder Breite mit keinem der bekannten Level übereinstimmen. Ich würde erst dann mit einem echten Fit beginnen, wenn die Startparameter einigermaßen gut sind."

Als Prozedur:

1. Fixieren Sie die Skala mit einem repräsentativen Datensatz. Fixieren Sie seine Normen bei 1 (unsere eigenen Daten, wenn sie jeden Kanal abdecken); lassen Sie die Norm jedes anderen Satzes variieren. So halten Sätze mit konsistenten Formen, aber einer anderen Skala den Fit nicht auf.
2. Säen Sie den Kanal mit der niedrigsten L jedes Paares für jedes Level. Geben Sie ihm eine kleine Amplitude ungleich Null (0.01 γ_W, in der Engine gesetzt; physikalische Platzhalter winzig, siehe den Seeding-Eintrag vom 2026-10-25), auch wenn die Literatur keinen Zweig zu diesem Kanal auflistet.
3. Jeder Kanal, der innerhalb des Fitbereichs öffnet, ist standardmäßig im Modell. Immer wenn der Fitbereich erweitert wird (ein neues Energiefenster oder ein Datensatz, der höher reicht), listen Sie jede Partition auf, die unterhalb des OBERSCHENKELS des Bereichs öffnet: jeden angeregten Zustand jedes Restkerns (ENSDF) und die anderen Leichtteilchen-Partitionen (d, t, ³He, ...), mit Schwellen Ex = sepE + e2. Fügen Sie vor dem Fitten ein Paar für jede hinzu, ohne gefragt zu werden: die niedrigste erlaubte L jedes Kanalspins auf jedem Level; gesät gemäß Punkt 2 auf Levels bei oder innerhalb von 0.5 MeV unterhalb der Schwelle und auf Hintergrundpolen, träge (0, fixiert) anderswo. Fügen Sie die neuen Ausgänge zu jedem summierten Segment hinzu (Gesamtquerschnitte, Gesamt (n,p), (n,α), ...). Begrenzen Sie KEIN Datenfenster an einer Schwelle. Eine Begrenzung ist eine Notlösung: protokollieren Sie sie im Readme mit dem Kanal, der sie erzwungen hat, und listen Sie sie für den Evaluator auf. (DeBoer 2026-10-30, 11B+α HE-Erweiterung: Der ELBE ¹⁴N+n Gesamtquerschnitt war bei E_n 5.1 MeV begrenzt, weil ¹⁴N(n,n₄) kein Paar hatte. Das ließ die oberen 1.2 MeV des Fits ohne seine stärkste Einschränkung, einen normfixierten Gesamtwert. Builder-Beispiel: 11B+a/10-27-26_HE_claude/model/add_pairs_he.py, 7 Paare n4 a3 d0 p1 n5 n6 p2.)
4. Level für Level, von niedriger Energie aufwärts. Polieren Sie ein Level nach dem anderen (seine Energie und Breiten sowie die freien Normen) gegen die umgebenden Daten und beobachten Sie, wie gut es sie abgleichen kann.
5. Dann Levels hinzufügen, wenn eine Resonanz deutlich vorhanden ist und kein bekanntes Level in Energie und/oder Breite dazu passt.
6. Erst dann ein echter (globaler) Fit: init einer Kampagne auf dem Ergebnis.

Warum (10B+α Stufe 1, 2026-10-25): Globale Polierungen von einem schlechten Start (χ²/N ≈ 200, 2-27-25 Levels mit neuen Kanälen nahe Null) tauschten die fehlende Stärke gegen Normalisierungen. Mit jeder Norm frei fielen fast alle auf 0.38-0.68 in 150 Auswertungen. Begrenzt auf 0.7-1.5, saßen acht auf einer Grenze und der Fit blieb bei χ²/N 12,7 stecken. Mit χ² ~ 10⁵ kosteten Norm-Priors von einigen Prozent nichts (10B+a/10-25-26_rmfit_stage1, _stage1b).

Dann, in einem neuen datierten Kampagnenverzeichnis (<reaction>/<M>-<D>-<YY>_rmfit_campaign/):

mkdir <dir> && cp <base>.azr <dir>/ && cp -r data <dir>/data && mkdir <dir>/output
python3 -m rmfit.cli <dir> init --base <dir>/<base>.azr [--sav <base>.sav] --nshards 24 \
    --flags '{"use_long_wavelength": false, "ignore_externals": true, "use_brune": true}' \
    --policy '{"theta2_cap": 1.0, "bg_theta2_cap": 3.0, "bg_energy": <Ex above the data>, "e_window": 0.3, "norm_range": [0.2, 5.0]}' \
    --search '{"top_k": 6, "pairs_per_group": 4, "stage1_nfev": 30, "stage2_nfev": 60, "union_nfev": 100}'

--flags wird direkt an pyazr.azure2() übergeben, daher wird die Parametrisierung dort gewählt: "use_brune": true (Brune, der Archivstandard), "use_park": true (Park: der Fitvektor hält die beobachteten reduzierten Breitenamplituden, Gamma = 2 P gamma^2; siehe das AZURE2-Skill zu "Parks Parametrisierung"), "use_brune": false (Standard Lane-Thomas). Eine Basis pro Kampagne – die Vektoren des Ledgers, .npz-Momentaufnahmen und .sav-Begleiter sind alle darin enthalten.

Optional --objective JSON (campaign.json objective, deBoer et al. 2017 Abschnitt zu Fitting): {"dataset_weight": "reduced", "dataset_key": "file", "loss": "sivia"}. dataset_weight: reduced ist die reduzierte Chi-Quadrat-Methode (das Chi-Quadrat jedes Datensatzes geteilt durch seine Anzahl von Punkten, neu skaliert mit N/K, so dass das Ziel eine Chi-Quadrat-Größe behält; Penalty-Zeilen ungewichtet) – sie verhindert, dass ein großer Satz mit kleinen Fehlern dominiert; loss: sivia ersetzt Chi-Quadrat durch Sivias breitere Verteilungsfunktion, -2 log[(1 - e^{-R^2/2})/R^2] - 2 log 2 (~R^2/2 für kleine Residuen, ~2 log R^2 für Ausreißer: Ausreißer werden heruntergewichtet, als ob ihr Fehlerbalken aufgeblasen wäre). Der Sivia-Verlust wird auf Residuen angewendet, die standardisiert durch das Referenz-Chi2/N jedes Datensatzes sind (loss_scale: dataset, Skalen werden von init aus der einfachen Baseline berechnet und in campaign.json gespeichert): ohne das, bei einem Modell mit Chi2/N ~ 20-300, sitzt jeder Punkt im logarithmischen Schwanz, die Daten verlieren ~10x ihr Gewicht gegenüber den quadratischen Norm-Penalties und der Fit driftet (13C+a, 2026-09-08: einfaches Chi2 701k -> 1.190k in einem Polieren, MANA aufgegeben, Norms auf Nominal geschnappt). Beide Methoden sind "statistisch inkorrekt, aber nützlich, wenn Fehlerbalken unterschätzt werden". Das Ziel ist eine Eigenschaft einer Kampagne: Kandidaten, die unter verschiedenen Zielen verifiziert wurden, sind nicht vergleichbar, daher bedeutet eine Änderung des Ziels ein neues Kampagnenverzeichnis (säen Sie es mit dem vorherigen Export). REPORT.md und segment_scores behalten das einfache Chi-Quadrat pro Datensatz, was auch immer das Ziel ist. Verifiziert in rmfit/tests/test_objective_13n.py.

init verifiziert die Baseline (eine vollständige Modellauswertung), registriert die Struktur, schreibt STATUS.md und das Job-Skript run_crc_rmfit (24-Core long-Knoten, mailt [email protected], -m abe). Erneutes Ausführen von init behält eine vorhandene Konfiguration bei, es sei denn, neue Werte werden angegeben. Policy-Bedeutungen: theta2_cap ist die Wigner-Limit-Box für physikalische Levels, bg_theta2_cap für Hintergrundpole (Levels mit Ex >= bg_energy, deren Energien fixiert bleiben) – 3.0 ist eine Anfangsschätzung, kein physikalischer Standard: Überprüfen Sie, wo die Hintergrundamplituden der Baseline bereits sitzen (das init-Cap-Audit), bevor Sie ihm vertrauen; 12C+alpha-elastisch benötigte ~100 (siehe den Protokolleintrag vom 2026-09-30); e_window ist die Energiefreiheit eines Levels pro Polierschritt (MeV); norm_range multipliziert die nominelle Normalisierung. narrow_window (optional, z.B. {"gamma_kev": 5, "factor": 3, "min_kev": 1}) hält ein Level, dessen freie Partialbreiten sich zu weniger als gamma_kev summieren, innerhalb von ±max(min_kev, factor·Γ) seiner aktuellen Energie anstelle von ±e_window, so dass ein Polieren ein schmales Level nicht von seiner Spitze wegtragen kann (das 13C+a 9/2+ ist in einem Tightening-Polish um 180 keV gedriftet). Shard-Anzahl = Kerne; Sharding ist exakt (Chi-Quadrat ist additiv über Segmente), daher bringen mehr Shards nur Geschwindigkeit.

Kostencheck bei einem neuen Modell (campaign.log nach init): Ein Shard-Ziel sollte wenige Sekunden und eine Jacobi-Matrix zig Sekunden dauern. Wenn ein Segment mit Ziel-Effekt- Faltung dominiert (wie Cierjacks auf 13C+a), faltet rmfit es selbst (model.ConvSpec); zusammengesetzte "Summen"-Segmente sind als Faltungsstücke erlaubt.

2b. Spezifikation, Audit, Entscheidungen (2026-11-07; Phase 1 von R-matrix/rmfit/DESIGN.md)

Vor init schreiben Sie die Spezifikation der Kampagne (spec.json, Vorlage rmfit/templates/SPEC_TEMPLATE.json, Schema in rmfit/spec.py): jeden Datensatz mit seiner Rolle (anchor = Norm auf Nominal fixiert; free mit prior_sigma; excluded mit Grund; screen), das Fenster, der eingefrorene Block, die Paare, die existieren müssen, Grenzen/Ziel/Suche, was der Treiber von alleine tun darf (pre_authorized: adopt_level true / false / Regeln, flip_adopt, dataset_off_adopt, ...), die Stoppregeln und die stehenden Entscheidungen mit ihrem Besitzer und Datum. Dann:

python3 -m rmfit.audit <base>.azr --out AUDIT.md       # Pre-Flight, keine Engine-Sitzung: Nullbreiten, 1-keV-Zusammenlegungen,
                                                       # nominelle Normen != 1, normError als BRUCH, FLAG-Spalten als
                                                       # Fehler, winzige Fehler, Duplikate, Spikes, Schwellen, <targetInt>
                                                       # auf Testsegmenten, Legacy-.sav-Namen, Ausgabepfad, Engine-Pin
python3 -m rmfit.cli <dir> init --base ... --spec spec.json   # flags/policy/search/objective/nshards aus der Spezifikation, sofern nicht
                                                       # angegeben; HIGH-Unstimmigkeiten mit der .azr verweigern das init
python3 -m rmfit.cli <dir> spec check                   # jederzeit: SPEC_CHECK.md; spec render -> SPEC.md; audit -> AUDIT.md

Ein HIGH-Audit-Befund wird behoben (oder in den stehenden Entscheidungen der Spezifikation als akzeptiert aufgezeichnet), bevor die Baseline erstellt wird. Während der Kampagne geht alles, was die Spezifikation nicht beantwortet, an DECISIONS.md (rmfit decisions listet, rmfit decide D-003 "adopt" --by DeBoer antwortet); ein Level-Hinzufügen, dessen accept die Spezifikation nicht vorab autorisiert, wird als accept-pending mit einer in der Warteschlange befindlichen Entscheidung aufgezeichnet und wird NICHT übernommen (die alte automatische Übernahme gilt nur für Kampagnen ohne Spezifikation). Spezifikationsentwürfe zum Kopieren: 10B+a/11-6-26_s5_highE/spec_draft.json, 13C+a/11-06-26_merged_regionD/spec_draft.json.

Die drei Leerlauf-Reviews von Abschnitt 3b werden generiert, nicht von Hand geschrieben, seit 2026-11-07:

python3 -m rmfit.cli <dir> audit --kind all            # audits/{input,data,literature}/PROMPT.md + leere FINDINGS.md
# übergeben Sie jede PROMPT.md an einen Hintergrund-Subagenten (Agent-Tool, ein günstigeres Modell, höchstens drei gleichzeitig); es schreibt FINDINGS.md
python3 -m rmfit.cli <dir> audit --findings            # unverifizierte (Kandidaten-)Zeilen jeder FINDINGS.md
python3 -m rmfit.cli <dir> audit --status data 1 confirmed --note "Zeile 4007 check