vibeflow-code-aster

name	vibeflow-code-aster
description	Use when preparing, running, debugging, post-processing, or developing VibeFlow/VibeCAE Code_Aster structural FEM and multiphysics workflows, including MED mesh handoff, .comm/.export files, material and boundary mapping from 0-caseDict/caseDict, run_aster execution, validation, and Code_Aster Python command development.

VibeFlow Code_Aster

This skill is responsible for connecting VibeCAE structural FEM, thermo-structural, and multiphysics problems to Code_Aster.

• Usage mode: generate Code_Aster cases from 0-caseDict/caseDict, run run_aster, and organize results.
• Development mode: write or maintain Code_Aster command-file templates, Python post-processing, adapters, and validation examples.

When to Use

• The current backend is code_aster.
• .comm, .export, .med, and result .rmed/.resu/.mess files need to be generated.
• Materials, loads, boundaries, contact, thermal analysis, or modal analysis need to be mapped from the unified physical description.
• run_aster, Code_Aster command syntax, MED meshes, or solver logs need debugging.

First Decide: Usage Mode or Development Mode

• Implementing structural/thermal/modal/contact analysis for the current case: use usage mode.
• Writing general .comm templates, Python adapters, post-processing parsers, or new algorithm wrappers: use development mode.
• If run_aster is unavailable or the environment is abnormal, switch to vibeflow-toolchain.
• If the mesh format or physical groups are missing, switch to vibeflow-mesh.

What to Read First

• physicalProblem, materials, regions, interfaces, boundariesLoadsInitials, mesh, numericalMethod, and execution in 0-caseDict/caseDict
• references/code-aster-playbook.md
• references/code-aster-practical-tips.md: software knowledge base, key concepts, failure interpretation, and adapter design points.
• MED/UNV/Gmsh artifacts and group naming in B-mesh/
• Existing scripts and logs in C-run/code_aster/ and D-post/

Inputs

• 0-caseDict/caseDict
• MED mesh or a mesh convertible to MED
• Materials, boundaries, loads, contact, and solution strategy
• .comm templates or reference cases

Outputs

• C-run/code_aster/<case>/case.comm
• C-run/code_aster/<case>/case.export
• C-run/code_aster/<case>/mesh.med
• C-run/code_aster/<case>/logs/*.mess
• C-run/code_aster/<case>/results/*
• Post-processing scripts and figures under D-post/code_aster/

Recommended Structure

C-run/code_aster/case-1/
├── case.export
├── case.comm
├── mesh.med
├── inputs/
├── results/
└── logs/

Usage Mode Workflow

1. Confirm execution.backend code_aster or that the user explicitly requested Code_Aster.
2. Check whether the mesh has group_ma/group_no semantics usable by Code_Aster.
3. Map materials, sections, boundaries, loads, contact, and analysis type from caseDict.
4. Generate .comm and .export, keeping paths relative to the case directory.
5. Execute run_aster case.export or a minimal command file.
6. Check fatal/error/alarm entries in the .mess log and confirm that result files were generated.
7. Write run status, result files, errors, and limitations into caseDict.

Development Mode Workflow

1. Define the development target: templates, command fragments, result parsing, MED conversion, material libraries, or contact/nonlinear strategies.
2. Record reference commands, inputs/outputs, and applicable physical scope.
3. Maintain templates with small benchmarks; do not debug first on a large case.
4. Structure .comm generation logic to avoid uncontrolled string concatenation.
5. When parsing .mess, extract only key errors, iteration status, convergence, and result summaries.
6. If a general capability is reusable, place it in UDF/ or a Studio adapter; keep the call record in the current case.

Core Rules

• Code_Aster cases must be reproducible around .comm, .export, MED meshes, and .mess logs.
• Group names must match the region/boundary semantics in caseDict.
• Do not write case-specific Code_Aster log paths into general templates.
• For nonlinear, contact, and thermo-structural coupling, record convergence criteria and fallback strategies for failures.
• Alarms in .mess are not always blocking, but fatal/error entries must be classified and handled.

Validation

• run_aster --help is available.
• .export or .comm can be accepted by run_aster.
• .mess has no unresolved fatal entries.
• Result files exist and can be read by post-processing scripts.
• caseDict records the backend, inputs, outputs, logs, and current state.

Fallback Rules

• Unclear physics/loads: return to vibeflow-case-dict
• Missing mesh groups: return to vibeflow-mesh
• Code_Aster environment unavailable: return to vibeflow-toolchain
• Results need visualization/reporting: switch to vibeflow-postprocess or vibeflow-report