Flujo de trabajo de proyectos de materiales
Comience con el objetivo de investigación y los archivos reales del proyecto, resultados, trabajos e instrucciones. Cuando la siguiente acción sea clara y esté dentro del alcance confirmado del investigador, ejecútela. De lo contrario, proponga una ruta breve: qué responde cada etapa, qué resultados avanzan y dónde el investigador debe elegir una alternativa científica. Una pregunta sobre el siguiente paso no aprueba por sí misma configuraciones científicas no elegidas ni cálculos adicionales. Use el idioma del mensaje del usuario y la convención del proyecto. No haga que una entrevista de incorporación sea un requisito previo para una tarea pequeña.
Escale el trabajo a la solicitud. Para una edición pequeña, inspeccione las configuraciones afectadas y los registros actuales, reutilice las herramientas existentes y ejecute verificaciones relevantes para el cambio. Vuelva a leer material sin cambios o repita una evaluación de respaldo/resultado aceptado solo cuando la nueva evidencia o la acción lo requiera. Construya un asistente para una necesidad recurrente concreta, no para cada cambio de parámetro. Siga los contratos de proyecto existentes; esta habilidad no requiere un nuevo marco de auditoría ni documentos de autorización duplicados.
Lea el valor predeterminado guardado del investigador si está presente: materials-project-workflow/DEFAULT.md en la carpeta de configuración del agente ($CODEX_HOME, normalmente ~/.codex, para Codex; ~/.claude para Claude Code). Es la preferencia de ese usuario, no una autoridad del proyecto; representa una decisión del investigador solo donde esta habilidad lo indica, y un proyecto puede anularlo. En el primer proyecto sustancial de un investigador sin un valor predeterminado guardado, invítelo a describir su flujo de trabajo habitual, sugiera mejoras y guarde solo la ruta que elija para proyectos posteriores; continúe una tarea única sin esta configuración. El ejemplo de valor predeterminado personal muestra lo que un valor predeterminado guardado para adsorción 2D puede contener; aplique sus configuraciones solo cuando el valor predeterminado del investigador o el proyecto las seleccione. Para un proyecto nuevo, registre las etapas elegidas, los recuentos de candidatos, las herramientas, las configuraciones de entrada significativas, el destino/retención de la copia de seguridad y los puntos de revisión en un archivo WORKFLOW.md corto del proyecto utilizando el esquema opcional; pregunte solo sobre capacidades desconocidas cuando una etapa seleccionada las necesite. Los proyectos posteriores confirman las diferencias en lugar de repetir las preferencias establecidas.
De forma predeterminada, optimice todos los candidatos de ML directamente a fmax = 0.01 eV/Å, luego seleccione estructuras, con 3000 pasos acumulativos del optimizador por estructura a menos que el investigador elija otro criterio de fuerza o límite de pasos. Establezca el ejecutor real en este límite desde el principio y termine antes con la convergencia, sin ejecuciones planificadas de pasos cortos. Cualquiera que sea la herramienta de ML utilizada, del valor predeterminado guardado o de la elección del proyecto, siga su manual sobre cómo ejecutarla, y escriba el criterio de fuerza y el límite de pasos explícitamente en cada ejecutor copiado; los valores predeterminados propios de una herramienta no los reemplazan. Esta habilidad, no un manual de herramienta, establece el criterio de fuerza, el límite de pasos (aumentarlo necesita al investigador), la selección de candidatos, la revisión, el monitoreo, los registros y el ESTADO; use el seguimiento programado en lugar del sondeo en sesión del manual, aparte de la verificación de inicio local. La lista de envío a DFT de una herramienta es una propuesta; aplique el recuento de candidatos acordado del proyecto y la regla de diversidad y observe cualquier diferencia. Recupere interrupciones genuinas, incluidos los tiempos de espera de walltime, de forma autónoma dentro del margen restante, sin importar las puertas de revisión de reinicio de DFT: use la función de reanudación de la herramienta donde exista; sin una, continúe una sola estructura desde su última estructura guardada con solo sus pasos restantes. Si la reanudación se niega, o un lote no puede transportar los pasos restantes de cada estructura, diagnostique e informe en lugar de buscar una solución alternativa. No agregue automáticamente un pase de ML grueso; se puede elegir otra ruta para un proyecto específico. Para ML local, preserve la capacidad de respuesta del escritorio con uso de recursos acotado. Elija los recursos locales del hardware real, la carga actual y el uso interactivo o dedicado; reutilice un perfil de máquina verificado, tenga en cuenta otros proyectos y verifique la configuración efectiva de trabajadores/hilos y el margen de memoria antes de aumentar el rendimiento. La presión de los recursos justifica un estrangulamiento autónomo, no configuraciones científicas más débiles.
Convierta la primera preparación de entrada de HPC para una nueva ruta y sitio en un punto de revisión del investigador. Explique el método propuesto, la secuencia de prueba/optimización, los recursos, el tiempo de pared por trabajo y los reinicios máximos con breves justificaciones; distinga las opciones acordadas de las propuestas. El acuerdo sobre un objetivo, como la optimización de volumen, o la provisión de una ruta/script de HPC, no aprueba un método no elegido, pruebas adicionales, cuenta o presupuesto. Prepare un borrador real representativo para revisión humana antes de organizar una serie completa o enviar un trabajo: estructura, INCAR, KPOINTS, identidad y método de generación de POTCAR, ejecutable, script de sitio adaptado, recursos y alcance del trabajo. Las lecturas autorizadas del proyecto y la generación de POTCAR se pueden utilizar para que ese borrador sea revisable. Prefiera el script exitoso del investigador de ese sitio HPC; de lo contrario, adapte el ejemplo oficial del sitio. Preserve el orden y formato de entrada consistentes del proyecto para que diff exponga cambios significativos. Una vez revisado, las estructuras relacionadas e intermedias bajo el mismo método proceden sin revisión por trabajo, incluso cuando su geometría y composición de POTCAR difieran. Revise un ejemplo real para un tipo de cálculo genuinamente nuevo o una ruta no relacionada. Una primera entrada revisada no es un resultado científico ni una concesión de ejecución ilimitada. El valor predeterminado guardado de un investigador puede eximir la selección de ML de HPC de esta revisión solo nombrando la herramienta, el sitio/cuenta y un límite de costo por selección; sin los tres, la revisión se aplica, y un proyecto puede endurecerlos pero no flexibilizarlos sin el investigador. Bajo dicha exención, pregunte antes de cualquier selección cuyo costo en el peor de los casos (cada estructura alcanzando el límite de pasos, incluidas las reanudaciones) pueda exceder el límite. Establezca el tiempo de pared a partir del rendimiento medido de la herramienta y las estadísticas de pasos, con margen; un tiempo de espera por debajo de él se reanuda, no es una ejecución planificada de pasos cortos. Registre el costo estimado y real (horas de núcleo o la unidad del sitio) en el registro de ejecución.
Para DFT, confirme el tiempo de pared por trabajo y los reinicios máximos por estructura de cada etapa en la revisión de la primera entrada. El trabajo inicial no cuenta como reinicio; cada continuación posterior o ejecución corregida en esa misma etapa sí, incluso después de un cambio de directorio u optimizador. Registre el uso en el registro de ejecución existente. Diagnostique antes de la continuación autónoma dentro de estos límites. Si el último reinicio permitido termina sin pasar la etapa, informe el diagnóstico en STATUS.md y obtenga revisión humana y una extensión explícita antes de otro trabajo. Una etapa convergente avanza normalmente; alcanzar el recuento por sí solo no detiene un trabajo que por lo demás se ejecuta de forma saludable. Honre cualquier presupuesto de proyecto adicional ya acordado.
Lleve a cabo el envío, monitoreo, transferencia de etapa y recuperación acotada ordinarios dentro de la ruta elegida sin pausar para cada cambio rutinario. Mantenga un único propietario de envío/reintento y registre una identidad de intento única más los resúmenes de entrada/script antes de llamar al planificador. Si se desconoce el resultado del envío, mantenga ese intento aislado: concilíelo contra el registro de ejecución, la cola, la contabilidad y las salidas; la ausencia de squeue o el retraso de sacct no es prueba de que no se aceptó ningún trabajo. No vuelva a enviar automáticamente hasta que el resultado se resuelva positivamente; pregunte si sigue siendo ambiguo. Para la optimización de geometría de VASP, gruesa o fina (no CI-NEB o IDM), use el optimizador elegido por el valor predeterminado del investigador o el proyecto, de lo contrario CG nativo (IBRION=2). Para las etiquetas, verificación, cambio y otras fallas, lea la guía de optimizador y recuperación; inspeccione las tendencias electrónicas e iónicas antes de una corrección justificada en lugar de reiniciar a ciegas. Preserve las entradas, salidas y fuente de cada intento. Si se confirma que un trabajo en vivo es NaN, fatalmente roto o claramente descontrolado mientras consume recursos, preserve la evidencia y cancele ese trabajo específico; diagnostique antes de cualquier reenvío. Pregunte cuando el modelo físico, el objetivo científico, el protocolo de comparación final, el sitio/cuenta o los límites de ejecución acordados cambien, o cuando persista una ambigüedad material. Solo compare las energías finales obtenidas bajo las configuraciones comunes del proyecto que afectan la energía.
Para rutas de reacción y estados de transición, lea la guía de CI-NEB/IDM. Ejecuciones de validación de frecuencia independientes solo para rutas que el investigador seleccione. Un cálculo de frecuencia de determinación de dirección de IDM es parte de una recuperación de IDM aprobada, no una validación automática de cada resultado de CI-NEB.
Para modelos tight-binding de Wannier y bucles de Wilson, lea la guía de Wannier; para invariantes a partir de valores propios de simetría (criterios de paridad, representaciones irreducibles, indicadores de simetría), lea la guía de valores propios de simetría.
Durante el trabajo activo de ML local o HPC, mantenga un STATUS.md en la raíz del proyecto legible en una pantalla: acciones pendientes, anomalías no resueltas, trabajo actual agrupado/próximo hito y algunos eventos recientes breves. Las secciones de acción/ excepción vacías contienen solo "ninguna"; enlace trabajos detallados, evidencia e historial más antiguo. Use la guía de estado, monitoreo y directorio. Al crear o adoptar esta página por primera vez, informe al investigador que está en uso, proporcione un enlace de archivo en el que se pueda hacer clic e indique brevemente qué rastrea y si se necesita su acción. Al final de cada paso de flujo de trabajo significativo, verifique la evidencia actual y actualice STATUS.md cuando el resultado, la acción necesaria, la anomalía o el siguiente paso hayan cambiado; haga esto antes de informar que el paso está completo o de transferir. Una verificación sin cambios no necesita reescritura de archivo. Use la guía vinculada para la programación y el acceso al trabajo activo; mantenga el progreso ordinario sin cambios en silencio y cancele el seguimiento cuando el trabajo esté conciliado. Mantenga los resultados adoptados inmediatamente localizables, la evidencia original rastreable y la copia de seguridad acordada actualizada. No cree enlaces del sistema de archivos dentro de carpetas sincronizadas en la nube como OneDrive; en HPC, un enlace simbólico final_choice con un FINAL_CHOICE.md vecino está bien.
Al entregar un POSCAR/CONTCAR al investigador para su visualización, ejecute scripts/clean_poscar_species.py sobre él si su línea de especies lleva etiquetas POTCAR o hashes (por ejemplo, Ti_sv/0a1b2c3d4), que VESTA no puede leer, y señale la copia _vesta.vasp; el original permanece sin cambios.
Esta habilidad es independiente. Use herramientas verificadas locales/del proyecto donde sea apropiado; AiiDA es una capa de procedencia opcional, nunca un requisito previo o un sustituto de archivos legibles.