Corrélation de la simulation avec Abaqus : le chemin parcouru pour relier un solveur à notre environnement logiciel

• Par Renaud Gras, CTO et co-fondateur d’EikoSim

Besoin de réalisation la corrélation d’un modèle de simulation Abaqus à des résultats d’essai de manière automatique ? Que ça soit en développant un script python, en utilisant réellement l’API C++ ou en développant nos parseurs, nous avons beaucoup expérimenté les fonctions de lecture et d’écriture de formats liés à ce solveur, que cela soit pour corréler des champs de déplacement ou déformation, ou simplement des résultats de jauges de déformation ou des capteurs d’effort. Revue des points forts d’Abaqus et des challenges à relever, en commençant par un peu d’historique pour notre cas particulier.

D’abord un besoin de recherche

Contrairement à beaucoup d’étudiants, notre rencontre d’Abaqus ne s’est pas faite via l’interface CAE, mais bien directement en utilisant le solveur en ligne de commande via des fichiers INP générés par un script externe. Pour ce travail, commencé en 2009, il a été nécessaire de créer ces modèles Abaqus à partir des maillages de corrélation d’images globale créés par le logiciel Correli-Q4, pour permettre une correspondance parfaite entre mesure et simulation. On procédait ensuite à l’identification de la position de la pointe en déterminant quelle simulation était la plus proche du résultat de mesure.

Dans ce cadre, nous ne faisions pas encore d’identification par méthode inverse, mais on peut décrire la procédure comme suit :

• Création avec Matlab/python d’une série de modèles dans des fichiers INP, grâce aux paramètres de base : maillage de corrélation d’images initial, scindé par une fissure représentés par une ouverture simple ou par des éléments cohésifs. La position de la pointe est paramétrable. La gestion de la table de connectivité est un vrai challenge notamment si on souhaite extruder un maillage 3D !
• Lancement des calculs en ligne de commande ;
• Extraction des champs de déplacement de l’ODB via un script python ;
• Comparaison des champs mesurés et simulés pour déterminer la pointe de fissure.

Plus tard, alors que la corrélation d’images adopte des maillages non-structurés, on commencera à lire des maillages depuis un fichier INP et on ajoutera une boucle de rétroaction pour l’identification de propriétés des matériaux. C’est notre passage au parsing de maillages éléments finis, avec un nombre limité d’exceptions, tous nos fichiers INP étant exportés depuis Abaqus CAE et donc écrits de manière très similaire.

Adaptation aux cas industriels

La création d’EikoSim a été l’occasion de découvrir la manipulation de données éléments finis, et de comprendre pourquoi nos clients ne pouvaient pas prendre le temps de développer leur propre intégration : faire un connecteur polyvalent et raisonnablement générique, c’est bien plus compliqué que le travail de laboratoire. Plusieurs raisons à cela :

• Les besoins industriels sont plus variés et couvrent une bonne partie des fonctionnalités d’Abaqus. En laboratoire, nous n’avions pas eu besoin d’intégrer des lois matériaux sous la forme d’UMAT, les orientations matériaux, les types d’éléments exotiques, les conditions aux limites, … La découverte de ces besoins nous a forcés à prioriser les développements.

• Les fichiers INP peuvent être exportés par d’autres pré/post qu’Abaqus CAE. Abaqus étant assez ouvert à d’autres formes de syntaxe de ces fichiers (par exemple dans l’ordre de définition des PART/INSTANCES), il faut que nous-mêmes puissions parser ces variantes de formats, ou décidions d’imposer à nos clients une syntaxe unique, quitte à leur demander de reprendre le fichier INP. Choix difficile !
• Il nous faut non seulement lire un fichier INP, mais également le réécrire dans une version “augmentée” par notre Digital Twin. Cela signifie que de nombreuses fonctionnalités que nous n’avons pas besoin d’interpréter pour les besoins de la mesure doivent tout de même être conservées pour être réécrites telles quelles et au bon endroit dans le fichier INP de sortie. Et pour celles que l’on interprète et qui doivent être remplacées dans le modèle, il faut également pouvoir identifier le bloc du fichier INP à remplacer et écrire le nouveau bloc généré par la suite logicielle EikoTwin.

Alors qu’avons-nous fait ?

Du fait des considérations précédentes et de notre expérience passée, l’utilisation de scripts python ne nous paraissait pas adaptée pour une intégration suffisamment versatile.

Deux options nous étaient alors accessibles grâce à l’API disponible dans la distribution du logiciel Abaqus, soit utiliser l’API python, soit utiliser l’API C++. Le choix s’est porté naturellement vers l’API C++, du fait que notre code logiciel est également en C++, mais également pour des raisons de performance.

Afin de répondre aux besoins de la suite logicielle EikoTwin, à savoir de réaliser la corrélation complète du modèle de simulation Abaqus, nous devons être capables :

• de lire dans le fichier d’entrée INP, le maillage éléments finis, les orientations matériaux assignées à chaque élément pour pouvoir exprimer les déformations dans ce repère local, les conditions aux limites, les matériaux et les “steps” de calcul ;
• de réécrire le fichier INP modifié ;
• de lire les résultats de simulation contenu dans le fichier odb ;
• de réécrire un fichier odb.

Premièrement, le fait de devoir lire un fichier d’entrée et un fichier de résultats implique de pouvoir attribuer ces résultats aux nœuds et aux éléments du format de maillage interne utilisé dans notre logiciel. Il est donc primordial de gérer l’information des numéros de nœuds et d’éléments originaux lus dans l’INP.

Deuxièmement, le fait de devoir modifier le modèle et de le réécrire nécessite de devoir stocker la structure et les informations du fichier d’entrée. Pour cela nous avons utilisé un arbre de stockage nous permettant de modifier des nœuds de cet arbre et de pouvoir réécrire simplement ce qui n’a pas été modifié.

D’autres besoins techniques s’ajoutent à cela, il faut notamment pouvoir :

• distribuer notre suite logicielle sans la lier explicitement à Abaqus mais que le client final soit capable avec son installation d’Abaqus de pouvoir utiliser notre sur-couche de l’API C++ ;
• gérer différentes version d’Abaqus présentes chez nos clients ;
• gérer d’autres solveurs par la suite (et notamment les formats liés à Hyperworks, Samcef…).

L’avantage d’utiliser le wrapper C++ codé par nos soins est le fait de pouvoir compiler une librairie statique par version d’Abaqus. Cela nous permet de pouvoir déterminer à l’exécution de la suite EikoTwin quelle version d’Abaqus le client utilise et d’utiliser les dlls de son installation

A quoi ressemble le résultat ?

Après quelques années de développement et de nombreuses lignes de code, notre intégration à Abaqus via ses API et notre parseur est encore perfectible, mais a déjà permis de résoudre de nombreux cas clients. Parmi les derniers développements en date, le pilotage d’études de sensibilités dans Abaqus permet aux utilisateurs d’utiliser le solveur comme “boîte noire” et d’estimer quels paramètres du modèle peuvent être identifiés sur un essai donné. La figure ci-dessous résume les connexions déjà possibles.

Prochaines étapes sur la roadmap pour une meilleure corrélation de votre résultat de simulation Abaqus ? La connexion à des serveurs de calcul (un challenge : ils sont sous Linux et notre logiciel sous Windows) et l’utilisation adéquate des éléments coques pour la DIC et la comparaison essai/calcul, indispensables pour les calculs de grandes structures.