test1card/femis-skill

FEM / CAE — structural · thermique · CFD · multiphysique

Ce skill régit les affirmations d'ingénierie — il ne pilote pas les solveurs et ne signe pas les conceptions. Il s'associe à un pilote de solveur / MCP (PyMAPDL, PyMechanical, un pilote Abaqus / OpenFOAM, OASiS, un MCP CAE) qui exécute ; ce skill décide si un résultat peut être affirmé, à quelle altitude, et quand un humain doit décider.

Vue d'ensemble

Gouverner l'analyse par éléments finis et CAE de bout en bout. Associé à un exécuteur (PyMAPDL, PyMechanical, PyFluent, un pilote Abaqus/OpenFOAM, un MCP CAE — voir "couche de gouvernance, pas l'exécuteur" ci-dessous) l'exécuteur localise le solveur installé, construit le fichier de commandes/script, et lance headless/batch ; ce skill guide et audite l'idéalisation, lit le journal pour la convergence, inspecte/analyse les résultats, et applique les pratiques professionnelles (idéalisation → maillage → connexions → contrôles de résolution → convergence → indépendance de maillage → V&V) sur chaque exécution. La méthodologie est indépendante du solveur ; la profondeur de travail ici est Ansys / Simcenter / Thermal Desktop, avec une largeur à travers Abaqus, LS-DYNA, MSC/Simcenter Nastran, COMSOL, OpenFOAM, Fluent, CFX, STAR-CCM+, CalculiX, Code_Aster (voir references/software-landscape.md).

Principes fondamentaux (appliquer comme portes) :

1. Aucun résultat n'est fiable tant que son erreur de discrétisation (maillage/pas de temps) n'est pas traitée — bornée et énoncée en INGÉNIERIE (par ex. changement de QoI lors du dernier raffinement, ou estimation ZZ/SPR sur un seul maillage), pleinement démontrée avec une étude GCI dans la plage asymptotique pour SIGNOFF ; un nombre sur un seul maillage rapporté sans aucune déclaration d'erreur n'est jamais un résultat. Plus les vérifications de convergence ci-dessous.
2. Converger la Quantité d'Intérêt (QoI), pas le pic — les pics aux coins vifs/charges ponctuelles/fissures sont des singularités qui ne convergent jamais.
3. La plupart des erreurs naissent en prétraitement (idéalisation, CL, connexions) — prendre ces décisions en amont.
4. Vérification avant validation ; calibration ≠ validation — et un agent ne doit pas prétendre à une signature sans preuve d'exécution.

Ce SKILL.md est le routeur. La profondeur vit dans references/ — charger une référence uniquement lorsque son sujet est en jeu.

Quand l'utiliser

• Structural (statique/modal/flambage/non linéaire/explicite), thermique (stationnaire/transitoire/rayonnement), CFD (RANS/LES, CHT), électromagnétisme (basse/haute fréquence), vibro-acoustique/NVH, multicorps, et multiphysique couplé (thermomécanique, FSI, EM-thermique).
• Défaillance et durabilité : rupture/tolérance aux dommages, fatigue (incl. vibratoire/spectrale), composites, plasticité/adaptation/rochet, flambage et stabilité, crash/impact/chute.
• Contact, résistance de contact thermique, connexions boulonnées/soudées/rigides ; maillage et indépendance de maillage (GCI) ; sélection d'élément/solveur/unités.
• Résolution headless/batch et analyse des résultats ; optimisation, calibration, identification de paramètre inverse / mise à jour de modèle.
• V&V / UQ ; sous-structuration/ROM ; cryogénie/vide/thermique spatial.
• Décider ce qu'un agent peut automatiser en headless vs ce qu'un humain doit faire (section suivante).

Pas pour : modélisation CAO pure ou problèmes mieux résolus par un calcul analytique fermé.

★ Contrat de capacité de l'agent & headless-vs-humain

Exactement qui fait quoi. Catégories : AGENT-HEADLESS (entièrement scriptable/batch, sans GUI) · AGENT-VIA-API (API Python/journal, nécessite une session + licence) · HUMAN-GUI (doit être interactif au moins une fois) · HUMAN-JUDGMENT (décision d'ingénierie que l'agent ne doit pas prendre seul) · LICENSE-GATED. Détails complets par plateforme : references/agent-automation-boundary.md.

Opération	Classification	Comment / pourquoi
Import CAO	AGENT-VIA-API	PyMAPDL/PyMechanical/run_journal import STEP/Parasolid
Nettoyage géométrie / forte dé-featurisation	AGENT-VIA-API + HUMAN-JUDGMENT	dé-featurisation/pincement scriptable ; réparation complexe + quoi dé-featuriser est un jugement
Maillage	AGENT-HEADLESS (Ansys) · SEED-IN-GUI (NX)	PyMAPDL/PyMechanical maille entièrement en headless ; les templates .fem/.sim NX ne se résolvent pas en batch → semiir une fois dans la GUI
Création/affectation de matériaux	AGENT-HEADLESS	scriptable sur toutes les plateformes ; fournir des données dépendantes de T
Contacts / connexions	AGENT-HEADLESS (construction) + HUMAN-JUDGMENT (type)	la définition est scriptable ; collé vs frottant / RBE2 vs RBE3 est un choix d'ingénierie
CL et charges	AGENT-HEADLESS	scriptable ; l'agent ne doit pas inventer le cas de charge
Exposer paramètres pour optimisation	AGENT-HEADLESS (PyMAPDL *SET) · HUMAN-GUI (Workbench P#, Expressions NX, tags HEEDS)	seul PyMAPDL est sans GUI pour le paramétrage
Résolution (stationnaire/transitoire/non linéaire)	AGENT-HEADLESS + LICENSE-GATED	ansys -b, nastran.exe, tmgnx, abaqus job=, fluent -g, OpenFOAM, cfx5solve -batch, starccm+ -batch
Résolution électromagnétique (machines/RF/courants de Foucault)	AGENT-VIA-API + LICENSE-GATED	PyAEDT (import ansys.aedt.core, non_graphical=True), COMSOL/getDP batch ; ports/excitations/balayages sont de la configuration d'ingénierie
Optimisation / DOE / calibration	AGENT-HEADLESS (PyMAPDL+SciPy, optiSLang -b, CLI HEEDS) + GUI-AUTHOR-ONCE	créer l'étude/les tags dans la GUI une fois, puis exécuter en headless
Extraction de résultats	AGENT-HEADLESS	PyDPF, pyNastran (.op2/.f06), .odb, SINDA .out, CGNS/VTK
Images/graphiques post	AGENT-HEADLESS	pyvista off-screen, ParaView pvbatch
Corrélation / mise à jour de modèle (MAC, appariement de nœuds)	HUMAN-GUI	l'appariement interactif test↔analyse des nœuds est un travail GUI
Création de template / .sim / projet (NX)	HUMAN-GUI	le registre de templates n'est pas initialisé en headless → pré-créer un seed, puis le piloter
Licence	LICENSE-GATED	chaque instance de solveur parallèle consomme son propre siège

Un agent ne doit JAMAIS faire automatiquement : choisir idéalisation / élément / type de contact / CL seul (HUMAN-JUDGMENT) · accepter un bouton de calibration coincé au bord de son corridor physique · rapporter un pic singulier ou un résultat non convergé comme résultat · prétendre à la vérification / indépendance de maillage / signature sans la preuve d'exécution · effectuer une poussée/écrasement irréversible sans autorisation.

Contrat d'appariement & exécuteur

Ce skill est la couche de gouvernance, pas l'exécuteur. Associez-le avec ce qui pilote le solveur (PyMAPDL, PyMechanical, un pilote Abaqus / OpenFOAM, OASiS, un MCP CAE) : l'exécuteur exécute ; ce skill régit l'affirmation. Ne faites confiance à aucune sortie de solveur sans provenance — un résultat est crédible uniquement lorsque l'exécuteur retourne :

• Manifeste d'exécution (run_manifest.json, template scripts/run_manifest_template.json) — la colonne vertébrale de traçabilité (NAFEMS R0033).
• Nom du solveur + version exacte — lu depuis la bannière/-help de l'installation détectée, jamais supposé.
• Hash du fichier d'entrée + hash du fichier de résultats (par ex. SHA-256 du .inp/.dat/.cdb et du .rst/.rth/.op2) — lie un nombre au fichier d'entrée exact et au résultat qui l'a produit.
• Preuve de la commande + des options — la ligne de lancement réelle, les options vérifiées par rapport à cette version (règle des commandes alignées sur la version, Étape 0).
• Espace de travail isolé — un répertoire de travail propre ; les sorties y sont écrites, ne remplaçant jamais un "final" antérieur sans un pointeur superseded_by.

Un résultat manquant de cette provenance est au mieux un artefact SMOKE/DEBUG — formulez-le comme tel (references/claim-templates.md).

Modes d'exécution (en choisir un par tâche — définit les portes obligatoires et ce que vous pouvez affirmer)

Mode	Quand l'utiliser	Portes obligatoires	Jamais
SMOKE	prouver que l'environnement/données/solveur/analyse s'exécute	Étape 0 ; résolution terminée ; fichier de résultats écrit et lisible	affirmer un nombre d'ingénierie ; régler quoi que ce soit
DEBUG	trouver la cause d'un échec	le test décisif pour le symptôme ; porte de connectivité si thermique	présenter une résolution diagnostique comme un résultat
ENGINEERING	résultat utilisable + vérifications de cohérence	unités ; connectivité ; bilan réactions/thermique/masse ; convergence ; extraction QoI ; vérification singularité	prétendre à la signature ; rapporter un pic singulier
SIGNOFF	livrable défendable	tout ENGINEERING + indépendance maillage & pas de temps (GCI, plage asymptotique) + rapport traçable + bornes d'erreur	sauter une porte ; éluder l'incertitude

Un résultat SMOKE/DEBUG est une vérification pipeline/physique, jamais une conclusion d'ingénierie — étiquetez-le.

★ Auto-vérification avant affirmation — répondre à TOUT avant d'énoncer un nombre d'ingénierie

C'est la porte qui rend le skill fiable. Avant de taper une contrainte, température, fréquence, marge, traînée, ou "cela passe", répondez à ces questions. Si une réponse est non / inconnu, vous n'avez pas de résultat — vous avez une sortie SMOKE/DEBUG : dites-le et arrêtez.

1. Mode ? Dans quel mode d'exécution suis-je, et ses portes obligatoires sont-elles passées ? (SMOKE/DEBUG ⇒ pas une conclusion d'ingénierie.)
2. Unités ? Système cohérent vérifié (vérification 1g-masse / calcul manuel) ; la densité n'est-elle pas corrompue par une mauvaise unité ?
3. Erreur de discrétisation traitée ? Erreur de maillage et de pas de temps bornée et énoncée (GCI pour SIGNOFF ; estimation ZZ/SPR sur un seul maillage pour ENGINEERING) ? Un nombre unique sur un seul maillage n'est jamais un résultat.
4. Singularité exclue ? La QoI est-elle un artefact de coin / charge ponctuelle / pointe de fissure ? Lire à distance ou linéariser avant de citer.
5. Bilan vérifié ? Réaction = appliquée ; bilan thermique/masse/énergie dans la tolérance ; convergence de l'historique des résidus, pas du code de sortie ?
6. Limite admissible nommée ? Y a-t-il une marge par rapport à un critère / code de conception NOMMÉ — pas un nombre brut ?
7. Porte de jugement humain franchie ? Ai-je choisi silencieusement un cas de charge, type de contact, limite admissible, dé-featurisation, ou signature ? Si oui — ARRÊTEZ et escaladez (references/escalation-examples.md).

Ensuite, formulez le résultat avec le template correspondant dans references/claim-templates.md. L'agent ne prétend jamais à la signature sans preuve d'exécution, et ne s'autorise jamais une décision d'ingénierie. Les options exactes du solveur / appels API sont eux-mêmes une affirmation — confirmez-les selon la règle des commandes alignées sur la version à l'Étape 0.

Étape 0 — TOUJOURS d'abord : découverte de l'environnement

Ne jamais supposer une version ou un chemin. Trouvez ce qui est installé/licencié, puis confirmez la plateforme + la physique + la QoI.

Get-ChildItem "C:\Program Files\ANSYS Inc" -Recurse -Filter "ANSYS*.exe" -ErrorAction SilentlyContinue | Select FullName   # MAPDL/Mechanical/Fluent/CFX
Get-ChildItem "C:\Program Files\Siemens" -Recurse -Include "nastran.exe","run_journal.exe","tmgnx.cmd","ugraf.exe" -ErrorAction SilentlyContinue
Get-ChildItem "C:\Program Files" -Recurse -Filter "abq*.bat" -ErrorAction SilentlyContinue   # Abaqus ; aussi `which icem`, OpenFOAM `foamVersion`
$env:ANSYSLMD_LICENSE_FILE; $env:LM_LICENSE_FILE
(Get-CimInstance Win32_Processor | Measure-Object NumberOfCores -Sum).Sum   # Cœurs PHYSIQUES

Linux : ansysNNN -b, nastran, abaqus, simpleFoam, fluent -g ; vérifiez $LM_LICENSE_FILE, nproc.

Commandes alignées sur la version (règle) : n'émettez jamais une commande de solveur, une option ou un appel API dont vous n'avez pas vérifié l'existence dans la version détectée — les versions renomment les options et font dériver les API. Confirmez avec l'-help/docs de la version installée avant de vous y fier, surtout pour ENGINEERING/SIGNOFF.

Workflow canonique (à exécuter dans l'ordre)

1. Objectif + QoI — le scalaire qui pilote la décision (marge, flèche, fréquence, T de pic, traînée). Pas "exécuter le modèle."
2. Type d'analyse — statique/modal/flambage/thermique/CFD/couplé ; linéaire vs non linéaire (matériau ? grande déflexion ? contact ? turbulence ?).
3. Idéaliser (le plus conséquent) — 1D/2D/3D ; symétrie uniquement si la géométrie et les charges et les CL sont symétriques ; dé-featuriser les caractéristiques non pertinentes. → references/meshing-convergence.md.
4. Matériaux — modèle constitutif correct ; propriétés dépendantes de la température ; en cryo utiliser ∫α(T)dT. → references/material-modeling.md.
5. Maillage — ordre/famille d'élément, raffinement aux concentrations, porte de qualité. → references/meshing-convergence.md.
6. Connexions & contact. → references/mechanical-connections.md, references/thermal-contact-resistance.md.
7. CL & charges — supprimer uniquement les modes de corps rigide appropriés à la dimensionnalité/type du modèle (un solide 3D non contraint en a 6 ; 2D, axisymétrique, coque uniquement et à symétrie cyclique diffèrent) ; charges sur des zones réalistes (jamais de charges ponctuelles/contraintes → singularités) ; soulagement d'inertie pour les corps libres. → references/advanced-methods.md.
8. Contrôles de résolution — type de solveur, cœurs, sous-pas + tolérances. → references/solver-numerics.md.
9. Vérifier — équilibre, indépendance maillage/pas de temps, historique de convergence. → references/vv-uq.md.
10. Valider — vs essai / calcul manuel / benchmark NAFEMS (calibration ≠ validation).
11. Post & rapport — bonne mesure, vérification moyenne vs non-moyennée, marges, hypothèses énoncées.

Unités cohérentes (CHOISIR UN système ; les solveurs sont sans unités)

Système	Longueur	Force	Contrainte/E	Masse	Densité (acier)	g
SI (m)	m	N	Pa	kg	7850 kg/m³	9,81 m/s²
mm-t-s (CAE courant)	mm	N	MPa	tonne	7,85e-9 t/mm³	9810 mm/s²

La densité est le corrupteur silencieux : une densité avec une mauvaise unité passe la statique mais ruine tous les résultats dynamiques/explicites/thermiques transitoires. /UNITS de MAPDL n'est que des métadonnées. Vérifiez avec un contrôle de masse 1g ou une fréquence naturelle de calcul manuel.

Sélection d'élément & qualité de maillage (profondeur : references/meshing-convergence.md)

• Quadratiques (nœuds milieux) pour la contrainte/géométrie courbe, en particulier les tétraèdres — éviter les TET4 linéaires pour la contrainte (déformation constante → trop rigide, convergence de contrainte lente ; acceptable uniquement comme remplissage loin de la QoI). Linéaire pour l'explicite/la grande déformation. (Le verrouillage en cisaillement affecte proprement les quadragones/hexaèdres linéaires à intégration complète en flexion — cisaillement parasite ; corrigez avec intégration réduite, modes incompatibles, ou quadratique — pas le même défaut que la rigidité à déformation constante des TET4.) Les solides quadratiques modernes résolvent une flexion modérée avec ~1 élément dans l'épaisseur comme point de départ (dû à la courbure — confirmer par convergence) ; les éléments linéaires en nécessitent plusieurs, et une flexion critique en précision veut ≥2 éléments quadratiques.
• Coque si épaisseur/longueur ≲ 1/10–1/20 ; solide pour contrainte 3D/à travers l'épaisseur ; poutre pour élancé. Tenir compte des…

[tronqué pour la traduction]