Que fait Workflow de projet pour matériaux ?
Commencez par l’objectif de recherche et les fichiers, résultats, jobs et instructions réels du projet. Lorsque l’action suivante est claire et dans le périmètre confirmé du chercheur, exécutez-la. Sinon, proposez un itinéraire court : ce que chaque étape répond, quels résultats font avancer, et où le chercheur doit choisir une alternative scientifique. Une question sur l’étape suivante n’approuve pas en soi des paramètres scientifiques non choisis ou des calculs supplémentaires. Utilisez la langue de l’invite de l’utilisateur et la convention du projet. Ne faites pas d’entretien d’intégration un prérequis pour une petite tâche.
Adaptez le travail à la demande. Pour une petite modification, inspectez les paramètres concernés et les enregistrements actuels, réutilisez les outils existants et exécutez les vérifications pertinentes pour le changement. Ne relisez du matériel inchangé ou ne répétez une évaluation de sauvegarde/résultat accepté que lorsque de nouvelles preuves ou l’action l’exigent. Créez un assistant pour un besoin récurrent concret, pas pour chaque changement de paramètre. Suivez les contrats de projet existants ; ce Skill n’exige pas un nouveau cadre d’audit ou des documents d’autorisation en double.
Lisez la valeur par défaut enregistrée du chercheur si elle est présente : materials-project-workflow/DEFAULT.md dans le dossier de configuration de l’agent ($CODEX_HOME, normalement ~/.codex pour Codex ; ~/.claude pour Claude Code). Il s’agit de la préférence de l’utilisateur, pas d’une autorité de projet ; elle remplace une décision du chercheur uniquement là où ce Skill le stipule, et un projet peut la remplacer. Lors du premier projet important d’un chercheur sans valeur par défaut enregistrée, invitez-le à décrire son workflow habituel, suggérez des améliorations et n’enregistrez que l’itinéraire qu’il choisit pour les projets ultérieurs ; poursuivez une tâche ponctuelle sans cette configuration. L’exemple de valeur par défaut personnelle montre ce qu’une valeur par défaut enregistrée pour l’adsorption 2D peut contenir ; n’appliquez ses paramètres que lorsque la valeur par défaut du chercheur ou le projet les sélectionne. Pour un nouveau projet, enregistrez les étapes choisies, les nombres de candidats, les outils, les paramètres d’entrée significatifs, la destination/la rétention de la sauvegarde et les points de révision dans un court WORKFLOW.md du projet en utilisant le plan facultatif ; ne demandez que les capacités inconnues lorsqu’une étape sélectionnée en a besoin. Les projets ultérieurs confirment les différences plutôt que de répéter les préférences établies.
Par défaut, optimisez tous les candidats ML directement jusqu’à fmax = 0,01 eV/Å, puis sélectionnez les structures, avec 3000 pas d’optimisation cumulés par structure sauf si le chercheur choisit un autre critère de force ou une limite de pas. Définissez l’exécuteur réel sur cette limite dès le départ et terminez plus tôt sur convergence, sans exécutions courtes planifiées. Quel que soit l’outil ML utilisé, de la valeur par défaut enregistrée ou du choix du projet, suivez son manuel pour son exécution et écrivez explicitement le critère de force et la limite de pas dans chaque exécuteur copié ; les valeurs par défaut d’un outil ne les remplacent pas. Ce Skill, et non un manuel d’outil, définit le critère de force, le plafond de pas (son augmentation nécessite le chercheur), la sélection des candidats, la révision, le suivi, les enregistrements et STATUS ; utilisez le suivi planifié plutôt que l’interrogation en session d’un manuel, en dehors de la vérification de démarrage local. La propre liste d’envoi vers DFT d’un outil est une proposition ; appliquez le nombre de candidats et la règle de diversité convenus du projet et notez toute différence. Récupérez les interruptions réelles, y compris les dépassements de temps walltime, de manière autonome dans la limite restante, sans importer de portes de révision de redémarrage DFT : utilisez la fonction de reprise de l’outil si elle existe ; sans cela, continuez une seule structure à partir de sa dernière structure enregistrée avec seulement ses pas restants. Si la reprise refuse, ou si un lot ne peut pas transporter les pas restants de chaque structure, diagnostiquez et signalez au lieu de contourner. N’ajoutez pas automatiquement un passage ML grossier ; un autre itinéraire peut être choisi pour un projet spécifique. Pour le ML local, préservez la réactivité du bureau avec une utilisation des ressources bornée. Choisissez les ressources locales à partir du matériel réel, de la charge actuelle et de l’utilisation interactive ou dédiée ; réutilisez un profil machine vérifié, tenez compte des autres projets, et vérifiez les paramètres effectifs de worker/thread et la marge mémoire avant d’augmenter le débit. La pression sur les ressources justifie un freinage autonome, pas des paramètres scientifiques plus faibles.
Faites de la première préparation d’entrée HPC pour un nouvel itinéraire et un nouveau site un point de révision par le chercheur. Expliquez la méthode proposée, la séquence de test/optimisation, les ressources, le temps walltime par job et le nombre maximal de redémarrages avec de brèves raisons ; distinguez les choix convenus des propositions. L’accord sur un objectif tel que l’optimisation de masse, ou la fourniture d’un chemin/script HPC, n’approuve pas une méthode non choisie, des tests ajoutés, un compte ou un budget. Préparez une ébauche réelle représentative pour révision humaine avant de mettre en scène toute une série ou de soumettre un job : structure, INCAR, KPOINTS, identité et méthode de génération POTCAR, exécutable, script de site adapté, ressources et périmètre de travail. Les lectures autorisées par le projet et la génération POTCAR peuvent être utilisées pour rendre cette ébauche révisable. Préférez le script réussi du chercheur sur ce site HPC ; sinon, adaptez l’exemple officiel du site. Préservez un ordre et un formatage d’entrée cohérents avec le projet pour que diff expose les modifications significatives. Une fois révisé, les structures et intermédiaires apparentés sous la même méthode progressent sans révision par job, même si leur géométrie et leur composition POTCAR diffèrent. Révisez un exemple réel pour un type de calcul véritablement nouveau ou un itinéraire non lié. Une première entrée révisée n’est pas un résultat scientifique ou un droit d’exécution illimité. La valeur par défaut enregistrée d’un chercheur peut exempter le screening ML HPC de cette révision uniquement en nommant l’outil, le site/compte et une limite de coût par screening ; sans les trois, la révision s’applique, et un projet peut les resserrer mais pas les assouplir sans le chercheur. Sous une telle exemption, demandez avant tout screening dont le coût dans le pire des cas (chaque structure atteignant le plafond de pas, reprises incluses) pourrait dépasser la limite. Définissez le temps walltime à partir du débit mesuré de l’outil et des statistiques de pas, avec une marge ; un dépassement de temps sous celui-ci est repris, pas une exécution courte planifiée. Enregistrez le coût estimé et réel (heures-cœur ou unité du site) dans l’enregistrement d’exécution.
Pour le DFT, confirmez le temps walltime par job et le nombre maximal de redémarrages par structure de chaque étape lors de la révision de la première entrée. Le job initial ne compte pas comme un redémarrage ; chaque continuation ou exécution corrigée suivante dans cette même étape en compte un, même après un changement de répertoire ou d’optimiseur. Enregistrez l’utilisation dans l’enregistrement d’exécution existant. Diagnostiquez avant une continuation autonome dans ces limites. Si le dernier redémarrage autorisé se termine sans passer l’étape, signalez le diagnostic dans STATUS.md et obtenez une révision humaine et une prolongation explicite avant un autre job. Une étape convergée progresse normalement ; atteindre le nombre seul n’arrête pas un job en cours autrement sain. Honorez tout budget de projet supplémentaire déjà convenu.
Effectuez la soumission, le suivi, le passage de relais entre étapes et la récupération bornée de routine dans l’itinéraire choisi sans faire de pause pour chaque changement de routine. Gardez un seul propriétaire de soumission/renvoi et enregistrez une identité de tentative unique ainsi que les condensés d’entrée/script avant d’appeler l’ordonnanceur. Si le résultat de la soumission est inconnu, gardez cette tentative isolée : reconciliez-la avec l’enregistrement d’exécution, la file d’attente, la comptabilité et les sorties ; l’absence de squeue ou un sacct retardé ne prouve pas qu’aucun job n’a été accepté. Ne renvoyez pas automatiquement tant que le résultat n’est pas résolu positivement ; demandez s’il reste ambigu. Pour l’optimisation géométrique VASP, grossière ou fine (pas CI-NEB ou IDM), utilisez l’optimiseur choisi par la valeur par défaut du chercheur ou le projet, sinon CG natif (IBRION=2). Pour les balises, la vérification, les changements et les autres échecs, lisez les conseils sur l’optimiseur et la récupération ; inspectez les tendances électroniques et ioniques avant une correction justifiée plutôt que de redémarrer à l’aveugle. Préservez les entrées, sorties et source de chaque tentative. Si un job en cours est confirmé NaN, fatalement cassé ou clairement incontrôlable tout en consommant des ressources, préservez les preuves et annulez ce job spécifique ; diagnostiquez avant toute nouvelle soumission. Demandez lorsque le modèle physique, la cible scientifique, le protocole de comparaison final, le site/compte ou les limites d’exécution convenues changent, ou lorsqu’une ambiguïté matérielle persiste. Ne comparez que les énergies finales obtenues avec les paramètres communs affectant l’énergie du projet.
Pour les chemins de réaction et les états de transition, lisez les conseils CI-NEB/IDM. Exécutez des calculs de validation de fréquence autonomes uniquement pour les chemins que le chercheur sélectionne. Un calcul de fréquence de recherche de direction IDM fait partie d’une récupération IDM approuvée, pas une validation automatique de chaque résultat CI-NEB.
Pour les modèles de liaison forte de Wannier et les boucles de Wilson, lisez les conseils Wannier ; pour les invariants à partir des valeurs propres de symétrie (critères de parité, représentations irréductibles, indicateurs de symétrie), lisez les conseils sur les valeurs propres de symétrie.
Pendant le travail ML local ou HPC actif, maintenez un STATUS.md à la racine du projet lisible en un écran : actions en attente, anomalies non résolues, travail en cours/prochain jalon regroupé et quelques événements récents courts. Les sections action/exception vides ne contiennent que « none » ; liez les jobs détaillés, les preuves et l’historique plus ancien. Utilisez les conseils sur le statut, le suivi et les répertoires. Lors de la première création ou adoption de cette page, informez le chercheur qu’elle est utilisée, fournissez un lien de fichier cliquable et indiquez brièvement ce qu’elle suit et si son action est nécessaire. À la fin de chaque étape de workflow significative, vérifiez les preuves actuelles et mettez à jour STATUS.md lorsque le résultat, l’action nécessaire, l’anomalie ou l’étape suivante a changé ; faites-le avant de signaler l’étape terminée ou de passer la main. Une vérification inchangée ne nécessite pas de réécriture de fichier. Utilisez les conseils liés pour la planification du travail actif et l’accès ; gardez les progrès inchangés ordinaires silencieux et retirez le suivi lorsque le travail est reconcilié. Gardez les résultats adoptés immédiatement trouvables, les preuves brutes traçables et la sauvegarde convenue à jour. Ne créez pas de liens du système de fichiers à l’intérieur de dossiers synchronisés dans le cloud tels que OneDrive ; sur HPC, un lien symbolique final_choice avec un FINAL_CHOICE.md voisin est acceptable.
Lorsque vous remettez un POSCAR/CONTCAR au chercheur pour visualisation, exécutez scripts/clean_poscar_species.py dessus si sa ligne d’espèce porte des étiquettes ou des hachages POTCAR (par exemple Ti_sv/0a1b2c3d4), que VESTA ne peut pas lire, et pointez vers la copie _vesta.vasp ; l’original reste inchangé.
Ce Skill se suffit à lui-même. Utilisez les outils locaux/de projet vérifiés le cas échéant ; AiiDA est une couche de provenance facultative, jamais un prérequis ou un substitut à des fichiers lisibles.