Add template mechanism for code_aster comm file generation from scenario

[basile-simvia]

Goal

Add a scenario-based assistant to generate a complete, editable code_aster study from a selected mechanical analysis scenario.

The assistant should generate both:

• a .comm command file;
• a matching .export file.

The generated study must be directly runnable and should use the mesh file selected by the user, especially to propose valid mesh group names when defining material assignments, boundary conditions, loads, and structural element properties.

This feature is not intended to replace AsterStudy. Its purpose is to create clean starter studies for common workflows.

---

Target Scenarios

The first version should support three mechanical scenarios:

1. Linear elastic static analysis

   • based on MECA_STATIQUE;
   • elastic material;
   • simple boundary condition;
   • simple mechanical load;
   • MED output.

2. Nonlinear static analysis

   • based on STAT_NON_LINE;
   • basic nonlinear static skeleton;
   • load ramp;
   • time/load increments;
   • convergence settings;
   • MED output.

3. Modal analysis

   • stiffness and mass matrix assembly;
   • CALC_MODES;
   • material density required;
   • boundary condition support;
   • MED output for modes.

---

Main User Workflow

The user should be able to run a command such as:

VSCode-Aster: Generate study from scenario

The assistant should then guide the user through the following steps:

1. Select the analysis scenario:

   • Linear elastic static analysis
   • Nonlinear static analysis
   • Modal analysis

2. Select the mesh file.

3. Read the mesh groups and make them available during the setup.

4. Select the modelization type.

5. Define material data.

6. Define structural element properties when needed.

7. Select boundary condition groups from the mesh.

8. Select load groups from the mesh.

9. Generate:

   • case.comm
   • case.export

The generated files should be editable and should follow clear naming conventions.

---

Mesh Group Integration

The assistant must use the selected mesh to propose available group names.

The user should not have to manually type group names when defining:

• material assignment groups;
• structural element groups;
• boundary condition groups;
• loaded groups.

Examples of expected choices:

Available groups:
- SOLID
- SHELL_PANEL
- CLAMPED_EDGE
- LOAD_FACE
- SUPPORT_NODES

The assistant should use the available group information to populate fields such as:

GROUP_MA="CLAMPED_EDGE"
GROUP_MA="LOAD_FACE"

or:

GROUP_NO="SUPPORT_NODES"

If the group type is known, the assistant should preferably filter the proposed groups depending on the use case.

For example:

Use case	Preferred group type
material assignment	volume, surface, or line element groups depending on modelization
shell/beam properties	structural element groups
pressure load	face or shell groups
nodal force	node groups
boundary condition	face, line, or node groups

---

Supported Modelizations

The assistant should support both continuum and structural modelizations.

The initial scope may be simplified, but the design must explicitly support structural elements.

Recommended first scope:

• 3D solid;
• plane strain or plane stress;
• shell or plate;
• beam.

The exact list can be adjusted depending on existing code and available mesh group metadata.

---

Structural Elements and AFFE_CARA_ELEM

When the selected modelization requires structural element properties, the generated .comm must include an AFFE_CARA_ELEM block.

Examples of modelizations requiring this step:

• shells;
• plates;
• beams;
• discrete elements, if supported later.

For structural cases, the generated concept should be named:

element_properties

and should be passed to the relevant solver or assembly command using:

CARA_ELEM=element_properties

Example pattern:

element_properties = AFFE_CARA_ELEM(
    MODELE=model,
    COQUE=_F(
        GROUP_MA="SHELL_GROUP",
        EPAIS=0.01,
        VECTEUR=(0.0, 0.0, 1.0),
    ),
)

For a beam case, the generated block may contain a simple section definition.

The first version does not need to support all possible structural options. A minimal, clear, editable block is acceptable.

---

Naming Conventions

Generated concept names must be in English, generic, and readable.

Recommended names:

Purpose	Concept name
mesh	mesh
model	model
material	material
material field	material_field
structural element properties	element_properties
boundary condition	boundary_condition
load	load
load ramp	load_ramp
time list	time_list
static/nonlinear result	result
modal result	modes
degree-of-freedom numbering	dof_numbering
stiffness matrix	stiffness_matrix
mass matrix	mass_matrix

Avoid short or cryptic names such as mat, bc, res, unless already required by an existing convention.

---

Generated .export File

The assistant must generate a matching .export file.

A minimal generated export file should include:

F comm case.comm D 1
F mmed mesh.med D 20
F mess case.mess R 6
F rmed case.rmed R 80

The generated .comm should use the same logical units:

mesh = LIRE_MAILLAGE(FORMAT="MED", UNITE=20)

and:

IMPR_RESU(
    FORMAT="MED",
    UNITE=80,
    RESU=_F(RESULTAT=result),
)

The generated .comm and .export files must be consistent with each other.

Ideally, the generated study should pass the study validation report introduced in the related validation issue.

---

Scenario Requirements

1. Linear Elastic Static Analysis

The generated .comm should include at least:

• DEBUT;
• LIRE_MAILLAGE;
• AFFE_MODELE;
• AFFE_CARA_ELEM when required by the selected modelization;
• DEFI_MATERIAU;
• AFFE_MATERIAU;
• AFFE_CHAR_MECA for boundary conditions;
• AFFE_CHAR_MECA for load;
• MECA_STATIQUE;
• CALC_CHAMP, if relevant;
• IMPR_RESU;
• FIN.

The generated solver call must include CARA_ELEM=element_properties when structural element properties are defined.

---

2. Nonlinear Static Analysis

The generated .comm should include at least:

• DEBUT;
• LIRE_MAILLAGE;
• AFFE_MODELE;
• AFFE_CARA_ELEM when required;
• DEFI_MATERIAU;
• AFFE_MATERIAU;
• AFFE_CHAR_MECA for boundary conditions;
• AFFE_CHAR_MECA for load;
• DEFI_FONCTION for load ramp;
• DEFI_LIST_REEL for increments;
• STAT_NON_LINE;
• COMPORTEMENT;
• CONVERGENCE;
• CALC_CHAMP, if relevant;
• IMPR_RESU;
• FIN.

The first version may use a simple nonlinear skeleton, for example:

• small strain formulation;
• elastic or simple elastoplastic material;
• default convergence parameters;
• one load ramp;
• one time list.

Advanced nonlinear features are out of scope for the first version.

---

3. Modal Analysis

The generated .comm should include at least:

• DEBUT;
• LIRE_MAILLAGE;
• AFFE_MODELE;
• AFFE_CARA_ELEM when required;
• DEFI_MATERIAU with density;
• AFFE_MATERIAU;
• AFFE_CHAR_MECA for boundary conditions;
• matrix assembly;
• CALC_MODES;
• optional mode normalization;
• IMPR_RESU;
• FIN.

The assistant should clearly require a density value for modal analysis.

For structural modelizations, element_properties must be passed to the matrix assembly step.

---

Suggested Simplified Scope for the First Version

To keep the first implementation realistic, the first version may be limited to:

• one material;
• one material assignment;
• one boundary condition;
• one load;
• one MED mesh input;
• one MED result output;
• simple linear elastic material parameters;
• simple nonlinear skeleton;
• simple modal extraction;
• a minimal set of structural properties for shells or beams.

The following items are out of scope for the first version:

• contact;
• thermal or thermomechanical analysis;
• multiple materials;
• multiple load cases;
• MFront behaviour generation;
• advanced beam sections;
• layered shells;
• large strain settings;
• automatic physical validation;
• automatic inference of boundary conditions from group names.

---

Acceptance Criteria

This issue is complete when:

1. A command exists to generate a study from a mechanical scenario.

2. The user can select one of the following scenarios:

   • Linear elastic static analysis;
   • Nonlinear static analysis;
   • Modal analysis.

3. The user can select a MED mesh file.

4. Mesh groups are read from the selected mesh and proposed to the user when selecting:

   • material groups;
   • structural element groups;
   • boundary condition groups;
   • load groups.

5. The assistant generates a .comm file with clear, generic English concept names.

6. The assistant generates a matching .export file.

7. The .comm and .export files use consistent logical units.

8. The linear elastic scenario generates a runnable MECA_STATIQUE skeleton.

9. The nonlinear scenario generates a runnable STAT_NON_LINE skeleton.

10. The modal scenario generates a modal analysis skeleton using stiffness and mass matrices.

11. If a structural modelization is selected, the generated .comm includes AFFE_CARA_ELEM.

12. If AFFE_CARA_ELEM is generated, the corresponding concept is passed to the relevant solver or assembly command through CARA_ELEM.

13. The generated files are formatted and intended to be edited by the user.

14. At least one test or fixture covers each supported scenario.

15. At least one test or fixture covers a structural modelization requiring AFFE_CARA_ELEM.

---

Example Output Structure

my_case/
├── my_case.comm
├── my_case.export
└── mesh.med

[poit0987-star]

Creating and reviewing workflows can be quite tedious. However, I believe that providing a basic workflow template would greatly improve productivity. Thank you for implementing this feature and for your continued efforts to improve the program.

Thank you, Simvia team!!