Workflow für Materialprojekte
Beginnen Sie mit dem Forschungsziel und den tatsächlichen Dateien, Ergebnissen, Jobs und Anweisungen des Projekts. Wenn die nächste Aktion klar und innerhalb des bestätigten Rahmens des Forschers liegt, führen Sie sie aus. Andernfalls schlagen Sie eine kurze Route vor: was jede Stufe beantwortet, welche Ergebnisse vorankommen, und wo der Forscher eine wissenschaftliche Alternative wählen muss. Eine Frage zum nächsten Schritt genehmigt nicht automatisch ungewählte wissenschaftliche Einstellungen oder zusätzliche Berechnungen. Verwenden Sie die Sprache der Benutzeranfrage und die Projektkonvention. Machen Sie ein Onboarding-Interview nicht zur Voraussetzung für eine kleine Aufgabe.
Skalieren Sie die Arbeit auf die Anfrage. Für eine kleine Änderung überprüfen Sie die betroffenen Einstellungen und aktuellen Aufzeichnungen, verwenden Sie vorhandene Werkzeuge wieder und führen Sie für die Änderung relevante Prüfungen durch. Lesen Sie unverändertes Material nur dann erneut oder wiederholen Sie eine verifizierte Sicherungs-/akzeptierte-Ergebnis-Bewertung, wenn neue Beweise oder die Aktion dies erfordern. Bauen Sie einen Helfer für ein konkretes wiederkehrendes Bedürfnis, nicht für jede Parameteränderung. Befolgen Sie bestehende Projektverträge; dieses Skill erfordert kein neues Prüfrahmenwerk oder doppelte Autorisierungsdokumente.
Lesen Sie die gespeicherte Voreinstellung des Forschers, falls vorhanden: materials-project-workflow/DEFAULT.md im Konfigurationsordner des Agenten ($CODEX_HOME, normalerweise ~/.codex für Codex; ~/.claude für Claude Code). Es ist die Präferenz dieses Benutzers, keine Projektautorität; es vertritt eine Forscherentscheidung nur dort, wo dieses Skill dies sagt, und ein Projekt kann es überschreiben. Bei einem ersten nennenswerten Projekt eines Forschers ohne gespeicherte Voreinstellung laden Sie ihn ein, seinen üblichen Workflow zu beschreiben, schlagen Sie Verbesserungen vor und speichern Sie nur die Route, die er für spätere Projekte wählt; führen Sie eine einmalige Aufgabe ohne dieses Setup fort. Die Beispiel-Personaleinstellung zeigt, was eine gespeicherte Voreinstellung für 2D-Adsorption enthalten kann; wenden Sie ihre Einstellungen nur an, wenn die Voreinstellung des Forschers oder das Projekt sie auswählt. Für ein neues Projekt zeichnen Sie gewählte Stufen, Kandidatenzahlen, Werkzeuge, sinnvolle Eingabeinstellungen, Sicherungsziel/Aufbewahrung und Überprüfungspunkte in einer kurzen Projekt-WORKFLOW.md unter Verwendung der optionalen Gliederung auf; fragen Sie nur nach unbekannten Fähigkeiten, wenn eine ausgewählte Stufe sie benötigt. Spätere Projekte bestätigen Unterschiede, anstatt festgelegte Präferenzen zu wiederholen.
Optimieren Sie standardmäßig alle ML-Kandidaten direkt auf fmax = 0,01 eV/Å und wählen Sie dann Strukturen aus, mit 3000 kumulativen Optimierungsschritten pro Struktur, es sei denn, der Forscher wählt ein anderes Kraftkriterium oder eine andere Schrittbegrenzung. Setzen Sie den eigentlichen Runner von Anfang an auf diese Grenze und beenden Sie früher bei Konvergenz, ohne geplante Kurzschrittläufe. Welches ML-Werkzeug auch immer verwendet wird, aus der gespeicherten Voreinstellung oder der Wahl des Projekts, befolgen Sie dessen Handbuch für die Ausführung und schreiben Sie das Kraftkriterium und die Schrittbegrenzung explizit in jeden kopierten Runner; die eigenen Voreinstellungen eines Werkzeugs ersetzen sie nicht. Dieses Skill, nicht ein Werkzeughandbuch, setzt das Kraftkriterium, die Schrittbegrenzung (deren Erhöhung bedarf des Forschers), Kandidatenauswahl, Überprüfung, Überwachung, Aufzeichnungen und STATUS; verwenden Sie die geplante Nachverfolgung anstelle eines manuellen In-Session-Pollings, abgesehen von der lokalen Startprüfung. Die eigene Sende-an-DFT-Liste eines Werkzeugs ist ein Vorschlag; wenden Sie die vereinbarte Kandidatenzahl und Diversitätsregel des Projekts an und notieren Sie etwaige Unterschiede. Beheben Sie echte Unterbrechungen, einschließlich Walltime-Timeouts, autonom innerhalb des verbleibenden Spielraums, ohne DFT-Neustart-Überprüfungsgates zu importieren: Verwenden Sie die Fortsetzungsfunktion des Werkzeugs, wo vorhanden; ohne eine solche fahren Sie mit einer einzelnen Struktur ab ihrer letzten gespeicherten Struktur mit nur ihren verbleibenden Schritten fort. Wenn die Fortsetzung verweigert wird oder ein Batch nicht die verbleibenden Schritte jeder Struktur tragen kann, diagnostizieren Sie und melden Sie, anstatt eine Problemumgehung zu versuchen. Fügen Sie nicht automatisch einen groben ML-Durchlauf hinzu; eine andere Route kann für ein bestimmtes Projekt gewählt werden. Für lokales ML bewahren Sie die Desktop-Reaktionsfähigkeit mit begrenzter Ressourcennutzung. Wählen Sie lokale Ressourcen basierend auf der tatsächlichen Hardware, der aktuellen Auslastung und der interaktiven oder dedizierten Nutzung; verwenden Sie ein verifiziertes Maschinenprofil wieder, berücksichtigen Sie andere Projekte und verifizieren Sie effektive Worker/Thread-Einstellungen und Speicherreserven, bevor Sie den Durchsatz erhöhen. Ressourcendruck rechtfertigt automatische Drosselung, nicht schwächere wissenschaftliche Einstellungen.
Machen Sie die erste HPC-Eingabevorbereitung für eine neue Route und einen neuen Standort zu einem Überprüfungspunkt für den Forscher. Erklären Sie die vorgeschlagene Methode, Test-/Optimierungssequenz, Ressourcen, Walltime pro Job und maximale Neustarts mit kurzen Begründungen; unterscheiden Sie vereinbarte Wahlmöglichkeiten von Vorschlägen. Die Zustimmung zu einem Ziel wie Bulk-Optimierung oder die Bereitstellung eines HPC-Pfads/Skripts genehmigt keine ungewählte Methode, hinzugefügte Tests, Konto oder Budget. Bereiten Sie einen tatsächlichen repräsentativen Entwurf zur menschlichen Überprüfung vor, bevor Sie eine ganze Serie starten oder einen Job einreichen: Struktur, INCAR, KPOINTS, POTCAR-Identität und Generierungsmethode, ausführbare Datei, angepasstes Standortskript, Ressourcen und Arbeitsumfang. Projektautorisierte Lesezugriffe und POTCAR-Generierung können verwendet werden, um diesen Entwurf überprüfbar zu machen. Bevorzugen Sie das erfolgreiche Skript des Forschers von diesem HPC-Standort; andernfalls passen Sie das offizielle Beispiel des Standorts an. Bewahren Sie eine projektkonsistente Eingabereihenfolge und Formatierung, damit diff sinnvolle Änderungen offenlegt. Nach der Überprüfung werden verwandte Strukturen und Zwischenprodukte unter derselben Methode ohne Job-für-Job-Überprüfung fortgesetzt, selbst wenn sich ihre Geometrie und POTCAR-Zusammensetzung unterscheiden. Überprüfen Sie ein tatsächliches Beispiel für einen wirklich neuen Berechnungstyp oder eine unabhängige Route. Ein überprüfter erster Input ist kein wissenschaftliches Ergebnis oder eine uneingeschränkte Ausführungsgenehmigung. Eine gespeicherte Voreinstellung des Forschers kann das HPC-ML-Screening von dieser Überprüfung nur ausnehmen, indem sie das Werkzeug, den Standort/das Konto und eine Kostenobergrenze pro Screening benennt; ohne alle drei gilt die Überprüfung, und ein Projekt kann sie verschärfen, aber nicht lockern. Unter einer solchen Ausnahme fragen Sie vor jedem Screening, dessen Worst-Case-Kosten (jede Struktur erreicht die Schrittgrenze, inklusive Fortsetzungen) die Grenze überschreiten könnten. Setzen Sie die Walltime basierend auf dem gemessenen Durchsatz des Werkzeugs und den Schrittstatistiken mit Spielraum; ein Timeout darunter wird fortgesetzt, kein geplanter Kurzschrittlauf. Zeichnen Sie geschätzte und tatsächliche Kosten (Kernstunden oder die Einheit des Standorts) im Laufeintrag auf.
Bestätigen Sie für DFT die Walltime pro Job und die maximalen Neustarts pro Struktur bei der ersten Eingabeüberprüfung. Der erste Job zählt nicht als Neustart; jede nachfolgende Fortsetzung oder korrigierte Ausführung in derselben Stufe zählt, auch nach einem Verzeichnis- oder Optimiererwechsel. Zeichnen Sie die Nutzung im bestehenden Laufeintrag auf. Diagnostizieren Sie vor autonomer Fortsetzung innerhalb dieser Grenzen. Wenn der letzte erlaubte Neustart endet, ohne die Stufe zu bestehen, melden Sie die Diagnose in STATUS.md und holen Sie eine menschliche Überprüfung und eine explizite Verlängerung ein, bevor Sie einen weiteren Job starten. Eine konvergierte Stufe schreitet normal voran; das Erreichen der Anzahl allein stoppt keinen ansonsten gesunden laufenden Job. Berücksichtigen Sie jegliches bereits vereinbarte zusätzliche Projektbudget.
Führen Sie gewöhnliche Einreichung, Überwachung, Stufenübergabe und begrenzte Wiederherstellung innerhalb der gewählten Route durch, ohne für jede routinemäßige Änderung anzuhalten. Behalten Sie einen Einreicher/Wiederholer bei und zeichnen Sie eine eindeutige Versuchskennung sowie Eingabe-/Skript-Digests auf, bevor Sie den Scheduler aufrufen. Wenn das Einreichungsergebnis unbekannt ist, halten Sie diesen Versuch abgeschirmt: gleichen Sie ihn mit dem Laufeintrag, der Warteschlange, der Buchhaltung und den Ausgaben ab; Abwesenheit von squeue oder verzögertes sacct ist kein Beweis dafür, dass kein Job angenommen wurde. Wiederholen Sie die Einreichung nicht automatisch, bis das Ergebnis positiv geklärt ist; fragen Sie, wenn es mehrdeutig bleibt. Verwenden Sie für die VASP-Geometrieoptimierung, grob oder fein (nicht CI-NEB oder IDM), den vom Forscherstandard oder Projekt gewählten Optimierer, andernfalls natives CG (IBRION=2). Lesen Sie für die Tags, Verifizierung, Umschaltung und andere Fehler die Optimierer- und Wiederherstellungsanleitung; überprüfen Sie elektronische und ionische Trends vor einer begründeten Korrektur, anstatt blind neu zu starten. Bewahren Sie die Eingaben, Ausgaben und die Quelle jedes Versuchs. Wenn ein laufender Job bestätigt NaN, fatal kaputt oder eindeutig außer Kontrolle ist, während er Ressourcen verbraucht, bewahren Sie Beweise auf und brechen Sie diesen spezifischen Job ab; diagnostizieren Sie vor jeder erneuten Einreichung. Fragen Sie, wenn sich das physikalische Modell, das wissenschaftliche Ziel, das endgültige Vergleichsprotokoll, der Standort/das Konto oder die vereinbarten Ausführungsgrenzen ändern oder wenn eine materielle Mehrdeutigkeit bestehen bleibt. Vergleichen Sie nur endgültige Energien, die unter den gemeinsamen energiebeeinflussenden Einstellungen des Projekts erzielt wurden.
Lesen Sie für Reaktionspfade und Übergangszustände die CI-NEB/IDM-Anleitung. Eigenständige Frequenzvalidierungsläufe nur für Pfade, die der Forscher auswählt. Eine IDM-Richtungsfindungsfrequenzberechnung ist Teil einer genehmigten IDM-Wiederherstellung, keine automatische Validierung jedes CI-NEB-Ergebnisses.
Lesen Sie für Wannier-Tight-Binding-Modelle und Wilson-Schleifen die Wannier-Anleitung; für Invarianten aus Symmetrie-Eigenwerten (Paritätskriterien, irreduzible Darstellungen, Symmetrieindikatoren) lesen Sie die Symmetrie-Eigenwert-Anleitung.
Pflegen Sie während aktiver lokaler ML- oder HPC-Arbeit eine STATUS.md im Projektstammverzeichnis, die auf einen Bildschirm lesbar ist: ausstehende Aktionen, ungelöste Anomalien, gruppierte aktuelle Arbeit/nächster Meilenstein und einige kurze aktuelle Ereignisse. Leere Aktionen/Ausnahme-Abschnitte enthalten nur „none“; verlinken Sie detaillierte Jobs, Beweise und ältere Historie. Verwenden Sie die Status-, Überwachungs- und Verzeichnisanleitung. Wenn Sie diese Seite zum ersten Mal erstellen oder übernehmen, teilen Sie dem Forscher mit, dass sie in Gebrauch ist, geben Sie einen anklickbaren Dateilink und geben Sie kurz an, was sie verfolgt und ob seine Aktion erforderlich ist. Überprüfen Sie am Ende jedes sinnvollen Workflow-Schritts die aktuellen Beweise und aktualisieren Sie STATUS.md, wenn sich das Ergebnis, die erforderliche Aktion, die Anomalie oder der nächste Schritt geändert hat; tun Sie dies, bevor Sie den Schritt als abgeschlossen melden oder übergeben. Eine unveränderte Prüfung erfordert kein Neuschreiben der Datei. Verwenden Sie die verlinkte Anleitung für die Planung und den Zugriff auf aktive Arbeiten; halten Sie gewöhnliche, unveränderte Fortschritte ruhig und beenden Sie die Nachverfolgung, wenn die Arbeit abgestimmt ist. Halten Sie übernommene Ergebnisse sofort auffindbar, Rohbeweise nachvollziehbar und die vereinbarte Sicherung aktuell. Erstellen Sie keine Dateisystemlinks innerhalb von cloud-synchronisierten Ordnern wie OneDrive; auf HPC ist ein final_choice-Symlink mit einer benachbarten FINAL_CHOICE.md in Ordnung.
Wenn Sie dem Forscher eine POSCAR/CONTCAR zur Ansicht übergeben, führen Sie scripts/clean_poscar_species.py darauf aus, wenn seine Spezieszeile POTCAR-Bezeichnungen oder Hashes trägt (z.B. Ti_sv/0a1b2c3d4), die VESTA nicht lesen kann, und weisen Sie auf die _vesta.vasp-Kopie hin; das Original bleibt unverändert.
Dieses Skill steht allein. Verwenden Sie verifizierte lokale/Projektwerkzeuge, wo angemessen; AiiDA ist eine optionale Provenienzschicht, niemals eine Voraussetzung oder ein Ersatz für lesbare Dateien.