O que Fluxo de trabalho para projetos de materiais faz?
Comece com o objetivo da pesquisa e os arquivos, resultados, trabalhos e instruções reais do projeto. Quando a próxima ação estiver clara e dentro do escopo confirmado do pesquisador, execute-a. Caso contrário, proponha uma rota curta: o que cada etapa responde, quais resultados avançam e onde o pesquisador deve escolher uma alternativa científica. Uma pergunta sobre o próximo passo não aprova, por si só, configurações científicas não escolhidas ou cálculos extras. Use o idioma da solicitação do usuário e a convenção do projeto. Não torne uma entrevista de integração um pré-requisito para uma tarefa pequena.
Escalone o trabalho conforme a solicitação. Para uma pequena edição, inspecione as configurações afetadas e os registros atuais, reutilize ferramentas existentes e execute verificações relevantes para a mudança. Releia material inalterado ou repita uma avaliação de backup/resultado aceito verificada somente quando novas evidências ou a ação assim o exigirem. Crie um auxiliar para uma necessidade recorrente concreta, não para cada alteração de parâmetro. Siga os contratos existentes do projeto; esta Skill não exige uma nova estrutura de auditoria ou documentos de autorização duplicados.
Leia o padrão salvo do pesquisador se presente: materials-project-workflow/DEFAULT.md na pasta de configuração do agente ($CODEX_HOME, normalmente ~/.codex, para Codex; ~/.claude para Claude Code). É a preferência do usuário, não uma autoridade do projeto; substitui uma decisão do pesquisador apenas onde esta Skill assim determina, e um projeto pode sobrescrevê-lo. No primeiro projeto substancial de um pesquisador sem um padrão salvo, convide-o a descrever seu fluxo de trabalho usual, sugira melhorias e salve apenas a rota que ele escolher para projetos posteriores; continue uma tarefa única sem essa configuração. O exemplo de padrão pessoal mostra o que um padrão salvo para adsorção 2D pode conter; aplique suas configurações somente quando o padrão do pesquisador ou o projeto as selecionar. Para um novo projeto, registre as etapas escolhidas, contagens de candidatos, ferramentas, configurações de entrada significativas, destino/retenção de backup e pontos de revisão em um WORKFLOW.md curto do projeto usando o esboço opcional; pergunte apenas sobre capacidades desconhecidas quando uma etapa selecionada necessitar delas. Projetos posteriores confirmam diferenças em vez de repetir preferências já estabelecidas.
Por padrão, otimize todos os candidatos de ML diretamente para fmax = 0,01 eV/Å, em seguida selecione estruturas, com 3000 passos cumulativos do otimizador por estrutura, a menos que o pesquisador escolha outro critério de força ou limite de passo. Defina o executor real para esse limite desde o início e termine mais cedo na convergência, sem execuções planejadas de passos curtos. Qualquer ferramenta de ML usada, seja do padrão salvo ou da escolha do projeto, siga seu manual para saber como executá-la e escreva o critério de força e o limite de passo explicitamente em cada executor copiado; os padrões próprios de uma ferramenta não os substituem. Esta Skill, não um manual de ferramenta, define o critério de força, o teto de passos (aumentá-lo requer o pesquisador), seleção de candidatos, revisão, monitoramento, registros e STATUS; use o acompanhamento agendado em vez da sondagem dentro da sessão de um manual, exceto pela verificação inicial local. A lista de envio para DFT de uma ferramenta é uma proposta; aplique a contagem de candidatos e a regra de diversidade acordadas do projeto e observe qualquer diferença. Recupere interrupções genuínas, incluindo timeouts de tempo de parede, autonomamente dentro do limite restante, sem importar portões de revisão/restart de DFT: use a função de retomada da ferramenta quando existir; sem uma, continue uma única estrutura a partir de sua última estrutura salva com apenas seus passos restantes. Se a retomada recusar, ou um lote não puder carregar os passos restantes de cada estrutura, diagnostique e relate em vez de contornar. Não adicione automaticamente uma passada de ML grosseira; outra rota pode ser escolhida para um projeto específico. Para ML local, preserve a capacidade de resposta do desktop com uso de recursos limitado. Escolha recursos locais com base no hardware real, carga atual e uso interativo ou dedicado; reutilize um perfil de máquina verificado, considere outros projetos e verifique as configurações efetivas de worker/thread e margem de memória antes de aumentar a taxa de transferência. A pressão sobre recursos justifica limitação autônoma, não configurações científicas mais fracas.
Torne a primeira preparação de entrada HPC para uma nova rota e local um ponto de revisão do pesquisador. Explique o método proposto, sequência de teste/otimização, recursos, tempo de parede por trabalho e número máximo de reinicializações com breves justificativas; distinga escolhas acordadas de propostas. A concordância sobre um objetivo, como otimização em massa, ou o fornecimento de um caminho/script HPC, não aprova um método não escolhido, testes adicionados, conta ou orçamento. Prepare um rascunho real representativo para revisão humana antes de encenar uma série inteira ou submeter um trabalho: estrutura, INCAR, KPOINTS, identidade e método de geração do POTCAR, executável, script adaptado ao local, recursos e escopo do trabalho. Leituras autorizadas pelo projeto e geração de POTCAR podem ser usadas para tornar esse rascunho revisável. Prefira o script bem-sucedido do pesquisador desse site HPC; caso contrário, adapte o exemplo oficial do site. Preserve a ordenação e formatação de entrada consistentes com o projeto para que diff exponha mudanças significativas. Uma vez revisado, estruturas relacionadas e intermediários sob o mesmo método prosseguem sem revisão por trabalho, mesmo quando sua geometria e composição de POTCAR diferirem. Revise um exemplo real para um tipo de cálculo genuinamente novo ou rota não relacionada. Uma primeira entrada revisada não é um resultado científico ou uma concessão de execução ilimitada. O padrão salvo de um pesquisador pode isentar a triagem HPC de ML desta revisão apenas nomeando a ferramenta, o local/conta e um limite de custo por triagem; sem todos os três a revisão se aplica, e um projeto pode apertar, mas não afrouxá-los sem o pesquisador. Sob tal isenção, pergunte antes de qualquer triagem cujo custo no pior caso (cada estrutura atingindo o teto de passos, retomadas incluídas) possa exceder o limite. Defina o tempo de parede a partir da taxa de transferência medida da ferramenta e estatísticas de passos, com margem; um timeout dentro disso é retomado, não uma execução planejada de passos curtos. Registre o custo estimado e real (core-horas ou a unidade do local) no registro de execução.
Para DFT, confirme o tempo de parede por trabalho e o número máximo de reinicializações por estrutura de cada etapa na revisão da primeira entrada. O trabalho inicial não conta como reinicialização; cada continuação subsequente ou execução corrigida nessa mesma etapa conta, mesmo após uma mudança de diretório ou otimizador. Registre o uso no registro de execução existente. Diagnostique antes da continuação autônoma dentro desses limites. Se a última reinicialização permitida terminar sem passar na etapa, relate o diagnóstico em STATUS.md e obtenha revisão humana e uma extensão explícita antes de outro trabalho. Uma etapa convergida avança normalmente; atingir a contagem sozinho não interrompe um trabalho em execução que esteja saudável. Honre qualquer orçamento adicional de projeto já acordado.
Execute submissão, monitoramento, passagem de etapa e recuperação limitada comuns dentro da rota escolhida sem pausar para cada mudança rotineira. Mantenha um proprietário de submissão/reenvio e registre uma identidade de tentativa única mais resumos de entrada/script antes de chamar o escalonador. Se o resultado da submissão for desconhecido, mantenha essa tentativa isolada: reconcilie-a com o registro de execução, fila, contabilidade e saídas; a ausência de squeue ou sacct atrasado não é prova de que nenhum trabalho foi aceito. Não reenvie automaticamente até que o resultado seja positivamente resolvido; pergunte se permanecer ambíguo. Para otimização de geometria VASP, grosseira ou fina (não CI-NEB ou IDM), use o otimizador escolhido pelo padrão do pesquisador ou pelo projeto, caso contrário CG nativo (IBRION=2). Para as tags, verificação, alternância e outras falhas, leia as diretrizes de otimizador e recuperação; inspecione tendências eletrônicas e iônicas antes de uma correção justificada, em vez de reiniciar cegamente. Preserve as entradas, saídas e fonte de cada tentativa. Se um trabalho ativo for confirmado como NaN, fatalmente quebrado ou claramente descontrolado enquanto consome recursos, preserve evidências e cancele esse trabalho específico; diagnostique antes de qualquer reenvio. Pergunte quando o modelo físico, o alvo científico, o protocolo de comparação final, o local/conta ou os limites de execução acordados mudarem, ou quando uma ambiguidade de material permanecer. Compare apenas energias finais obtidas sob as configurações comuns de efeito energético do projeto.
Para caminhos de reação e estados de transição, leia as diretrizes de CI-NEB/IDM. Execute execuções de validação de frequência independentes apenas para caminhos que o pesquisador selecionar. Um cálculo de frequência para determinação de direção IDM faz parte de uma recuperação IDM aprovada, não validação automática de todo resultado CI-NEB.
Para modelos tight-binding de Wannier e loops de Wilson, leia as diretrizes de Wannier; para invariantes de autovalores de simetria (critérios de paridade, representações irredutíveis, indicadores de simetria), leia as diretrizes de autovalor de simetria.
Durante trabalho local ativo de ML ou HPC, mantenha um STATUS.md na raiz do projeto legível em uma tela: ações pendentes, anomalias não resolvidas, trabalho atual agrupado/próximo marco e alguns eventos recentes curtos. Seções de ação/exceção vazias contêm apenas “none”; vincule trabalhos detalhados, evidências e histórico mais antigo. Use diretrizes de status, monitoramento e diretório. Ao criar ou adotar esta página pela primeira vez, informe ao pesquisador que ela está em uso, forneça um link clicável para o arquivo e indique brevemente o que ela rastreia e se a ação dele é necessária. Ao final de cada etapa significativa do fluxo de trabalho, verifique as evidências atuais e atualize STATUS.md quando o resultado, a ação necessária, a anomalia ou o próximo passo mudar; faça isso antes de relatar a etapa como concluída ou passar adiante. Uma verificação inalterada não precisa de reescrita de arquivo. Use as diretrizes vinculadas para agendamento e acesso ao trabalho ativo; mantenha o progresso normal inalterado silencioso e remova o acompanhamento quando o trabalho for reconciliado. Mantenha os resultados adotados imediatamente encontráveis, as evidências brutas rastreáveis e o backup acordado atualizado. Não crie links do sistema de arquivos dentro de pastas sincronizadas em nuvem, como OneDrive; no HPC, um link simbólico final_choice com um FINAL_CHOICE.md vizinho é aceitável.
Ao entregar um POSCAR/CONTCAR ao pesquisador para visualização, execute scripts/clean_poscar_species.py nele se sua linha de espécies carregar rótulos ou hashes de POTCAR (por exemplo, Ti_sv/0a1b2c3d4), que o VESTA não consegue ler, e aponte para a cópia _vesta.vasp; o original permanece inalterado.
Esta Skill é independente. Use ferramentas locais/de projeto verificadas quando apropriado; AiiDA é uma camada opcional de procedência, nunca um pré-requisito ou substituto para arquivos legíveis.