Ingénierie numérique et Python : faits pour s’entendre bien sûr !

Andres Rodriguez-VillaEn mai 2016, Ceetron a mis sur le marché une interface Python vers 3D Components. En tant que coupable d’une grande partie de cet interfaçage, je me suis vu « gentiment proposer » d’écrire un blog autour de Python et son utilité pour les développeurs utilisant 3D Components. L’éditeur du blog a tout de suite donné le ton : « Andres, t’as qu’à écrire un truc marketing à propos de notre dernière release », du genre « Ecrire des applis d’ingénierie performantes en Python : yes, we can ». Je me suis dit que c’était un peu pipeau, puisque la plupart des ingénieurs numériques savent les limitations de Python : tout seul, ça ne suffit pas ; il faut la performance d’un langage compilé derrière. Du coup, je n’ai jamais écrit ce blog « gentiment proposé » par mon éditeur et j’ai eu raison – il me doit une bière désormais.

Un an et un président de la République plus tard, j’ai désormais eu l’occasion de travailler avec des ingénieurs mécaniciens férus de Python sur leurs projets. Et j’ai décidé de revenir sur le sujet pour raconter ma propre histoire sur la place prépondérante qu’occupe Python dans le milieu du calcul scientifique. J’en ai profité pour discuter du sujet avec notre DT, Fredrik Viken et recueillir quelques propos de Tim Hunter, PDG de Wolf Star Technologies (notre client et éditeur de logiciels de mécanique appliquée écrits en Python – voir http://www.wolfstartech.com/). Mais mon récit démarre bien plus tôt, quand tout a commencé pour notre secteur d’activité : les années 80. Pourquoi ce flashback ? Tout simplement pour comprendre certains éléments qui expliquent l’utilité flagrante de Python aujourd’hui. Allons-y.

De manière évidente, l’importance des logiciels de simulation dans l’ingénierie n’a cessé de croître au cours de 30 dernières années, passant de « simples » aides à la décision à de réels outils intégrés à la conception. Le développement simultané des méthodes numériques, des modèles physiques et de la puissance de calcul confère aujourd’hui à ces outils un rôle stratégique dans des secteurs aussi majeurs que l’aéronautique, l’énergie ou l’automobile. De nos jours, pas une pièce n’est conçue, ni même fabriquée sans l’assistance de l’ordinateur.

L’émergence du marché du logiciel de simulation en ingénierie démarre dans les «eighties». A ses débuts sa structure est très différente de celle que nous connaissons : l’édition de ces logiciels se fait le plus généralement dans des startups de chercheurs, ou alors à l’abri des regards au sein des entreprises industrielles en quête d’avantage concurrentiel. Dans les deux cas, les offres sont centrées sur le « solveur », le composant qui transforme données en résultats prédictifs. Ce qui somme toute, n’a rien d’étonnant : le « solveur » est le cœur de ce métier.

Vu les limitations matérielles du moment, les défis du “calculer vite et juste” sont immenses et la plupart des ressources sont affectées à cet objectif. Il reste alors bien peu de forces vives pour développer des interfaces graphiques « ayant de la gueule » et conviviales (sans parler d’interfaces de programmation pour l’analyse et l’exploitation des résultats par les utilisateurs finaux).

Au bout d’une décennie de consolidation, les startups de chercheurs les plus intrépides sont devenues de solides éditeurs de logiciel, et la plupart des industriels ont abandonné l’idée de coder des algorithmes en interne. Les packages logiciels des années 90 ont dépassé le stade du « tout solveur » et incluent de interfaces graphiques de qualité ainsi qu’une gamme de fonctionnalités annexes mais très utiles : base de données, outils de reporting,… ainsi que les premières interfaces de programmation permettant de traiter à façon les résultats de calcul.

A l’arrivée du nouveau millénaire, ces offres très complètes et mûres attirent la convoitise de nouveaux poissons (et des gros) : les éditeurs de CAO. Initialement dévouées à la conception d’objets, ces entreprises ont lentement étendu leur offre à, entre autres, la prédiction des propriétés d’usage de ces objets une fois conçus. Vu la position privilégiée de la CAO dans le cycle produit (au tout début) et leur puissance financière, ces entreprises se sont livrées (et se livrent encore) à de nombreuses acquisitions d’éditeurs de simulation (Autodesk a par exemple procédé à environ 50 acquisitions depuis 1993, parmi elles Moldflow en 2008 et Blue Ridge Numerics en 2011 ; Siemens PLM a plus récemment acquis LMS, Cd-Adapco et Mentor Graphics). Notons que, malgré la voracité des gros poissons, certains éditeurs sont parvenus à leur échapper au prix d’une même stratégie de croissance externe, citons par exemple ESI ou Altair.

Et pendant ce temps-là ? Eh bien, pendant que les acteurs historiques du marché s’entremangent pour croître dans un marché technologiquement statique (le calcul parallèle apparu 20 ans plus tôt est la dernière réelle révolution), nous assistons depuis 2010 à l’émergence d’un réel changement des règles du jeu. Notre décennie a vu arriver des offres singulièrement nouvelles : nouvelles de par leur moyens de production (solveurs open source), nouvelles par l’infrastructure proposée (le fameux Cloud) et nouvelles par leur stratégie de vente (SaaS). Comme dans tant d’autre secteurs – mais avec un temps de retard – les acteurs historiques du calcul scientifique voient ces nouveaux venus leur imposer des nouvelles règles et changer la donne avec leurs offres en phase avec notre environnement technologique (par ex. SimScale, OneShape, Penguin Computing, …)

Voilà résumées en quelques paragraphes ma vision (100% vécue !) de l’émergence, la croissance et la situation courante du marché de l’édition de logiciels d’ingénierie numérique.

Et l’ingénieur calcul, dans tout ça ? Où en est l’utilisateur final ? Dans le pétrin, selon moi. On peut imaginer que dans les années 80, quand les outils étaient « simples » et qu’on pouvait se contenter de simuler les choses de façon isolée, la courbe d’apprentissage ne faisait peur à personne. Aujourd’hui, ce n’est plus la même affaire : les systèmes sont très sophistiqués et les études complètes impliquent souvent l’utilisation de plusieurs solveurs, les résultats de l’un servant plus ou moins directement de données à l’autre. La pente de la courbe est plus proche de celle de l’Alpe d’Huez.

La mise en données d’un calcul est très proche de l’application réelle et du métier de l’utilisateur, de par sa terminologie et ses spécificités. Il me semble difficile de la généraliser et de ce fait, je crains que l’ingénieur ne doive maîtriser les différents logiciels sur ce point.

Il n’en va pas de même pour l’étape de post-process, celle où les résultats sont analysés (inspectés) et exploités (traités par calcul). Je suis convaincu qu’ici les choses changent et qu’une approche générique est envisageable.

Même si certaines opérations d’analyse de résultats ont un lien avec l’application réelle, la plupart des outils nécessaires sont génériques : plans de coupes, isosurfaces, capteurs, génération de courbes, … Il n’est pas nécessaire d’utiliser différents GUI, et il me semble qu’il y a des gains d’efficacité substantiels si c’est ce que vous faites aujourd’hui. Un outil unique pour analyser les résultats vous permettrait d’unifier vos process et passer plus de temps à utiliser les solveurs qu’à découvrir leur GUI.

En ce qui concerne l’exploitation des résultats, l’ingénieur calcul serait content de pouvoir les lire de manière transparente depuis un logiciel, effectuer des calculs dessus et peut-être réutiliser le tout comme donnée d’un autre logiciel. Suivant la nature des calculs à effectuer sur les résultats, ces opérations sont aujourd’hui réalisées avec une multitude d’outils et technologies : feuilles Excel (avec ou sans macros VBA), moulinettes en langage compilé (C++, Fortran, C) ou en langage scripté (DOS, VB, shells Linux, …)

C’est ici qu’intervient Python. Les débuts remontent à 1994 (sortie de la version 1.0, dont l’écriture a débuté en 1989). Le créateur, Guido Van Rossum, un développeur accompli (il obtiendra plusieurs prix par la suite, parmi lesquels la « 2001 Award for the Advancement of Free Software » de la FSF, la « NLUUG Award 2003 » et le titre honorifique de « Distinguished Enginner » de l’ACM en 2006), écrit à propos de Python : « en décembre 1989, je cherchais un projet de programmation ludique, question de rester occupé pendant les vacances de Noël. Mon bureau serait fermé, mais j’avais un PC à la maison et pas grand-chose de plus à ma disposition. J’ai décidé d’écrire un interpréteur pour un nouveau langage de script qui me trottait dans la tête depuis un moment : un descendant d’ABC qui plairait aux hackeurs UNIX/C. J’ai choisi « Python » comme nom de code du projet parce que j’étais d’humeur irrévérencieuse (et que je suis un grand fan des Monty Python et leur Flying Circus). » Ce petit projet « pour s’amuser » allait devenir Python : un langage de script standard et puissant qui permet de travailler avec des structures de données complexes codées dans d’autres langages, et de réaliser des opérations dessus à partir d’un simple éditeur de texte.

Spectrum rankingAujourd’hui, le langage est couramment enseigné dans les écoles d’ingénieurs, et est massivement utilisé dans l’ingénierie numérique (il ne doit pas être loin d’être le langage le plus populaire dans ce milieu). Selon l’IEEE, tous secteurs confondus, Python est le troisième langage le plus utilisé, après le C et Java, mais devant le C++  (source: http://spectrum.ieee.org/computing/software/the-2016-top-programming-languages).

Python permet non seulement de produire du code très propre et lisible, il a également l’énorme avantage d’être une référence quasi-totale. Quel que soit le besoin, on peut se procurer des modules prêts à l’emploi en quelque clics. Par exemple, NumPy (ou SciPy) pour le calcul scientifique, ou encore MatPlotLib pour générer des courbes. Depuis ses débuts, la communauté d’utilisateurs de Python n’a cessé de croître et la quantité de fonctionnalités réutilisables a suivi. Il s’agit là du plus grand succès de standardisation en termes de programmation.

De ce fait, il n’est pas étonnant de voir qu’un nombre croissant d’éditeurs de logiciels scientifiques proposent aujourd’hui des interfaces de programmation (API) en Python à leurs utilisateurs, leur permettant d’accéder aux résultats (voire à l’interface graphique pour la personnalise) (p.ex Abaqus, Ansys, MSC Mentat). Je m’attends à ce que ce mouvement s’amplifie dans les années qui viennent.

Le véritable problème de l’ingénieur calcul reste inchangé : comment rendre son travail de post-process plus efficace dans un environnement multi-logiciel complexe. D’un côté, les interfaces graphiques (GUI) pour analyser les résultats sont toutes différentes, et de l’autre les interfaces de programmation (API) pour les exploiter ne seront jamais les mêmes (s’il y en a). Cela fait beaucoup d’interfaces à maîtriser afin de devenir complètement opérationnel. L’idée d’utiliser une plateforme généralisée et unificatrice n’est pas loin, un outil capable de lire une grande variété de formats de résultats pour ensuite les exposer graphiquement à l’analyse et programmatiquement (en Python !) à l’exploitation.

C’est cette vision d’une plateforme commune répondant aux besoins des ingénieurs numériques, que mes collègues de chez Ceetron et moi-même avons fait progresser ces deux dernières années. Comme dit en introduction, une première version d’interface Python a été livrée en mai 2016 avec la version 3D Components 1.4.0. Depuis, notre produit phare est essentiellement devenu une plateforme de développement qui couvre a) l’ouverture de bases de résultats diverses (pratiquement tous les formats standard de l’industrie sont supportés), b) la construction de visualisations 3D de haute qualité (applications destkop ou web) pour les analyser et c) l’écriture des scripts Python pour les exploiter en profondeur.

Sur cet aspect d’exploitation des résultats, nous travaillons actuellement sur l’enrichissement de fonctionnalités spécifiques (combinaison linéaire de modèles, réponse en phase sur fréquence donnée d’un calcul modal, …) afin de simplifier encore plus le travail de nos clients. Selon mon DT et ami Fredrik Viken, « Dès le départ, nous souhaitions résoudre ce que nous voyions comme un problème auquel sont confrontés des centaines de milliers d’ingénieurs au quotidien, en proposant une plateforme de programmation indépendante du solveur qui permettrait de mener à bien analyse et exploitation de résultats dans un environnement unique. A l’avenir, Ceetron a l’intention de renforcer ses efforts sur l’ouverture à Python. Nous évaluons notamment l’opportunité de fournir une interface ouverte sur notre nouveau produit de post-process « 3D Viewer Pro », permettant ainsi de réduire le temps de développement pour ceux qui souhaiteraient prendre ce produit comme base pour le leur. Ils démarreraient ainsi avec un post-processeur complet, qu’ils pourront étendre aisément grâce à Python. »

Tim Hunter WolfstarJe vous avais promis un commentaire de Dr. Tim Hunter, PDG de Wolf Star Technologies : « Nous avons démarré ce projet commun sur True-Load au printemps 2016, après avoir évalué rigoureusement d’autres alternatives. Ce qui m’a le plus impressionné dans ce projet, c’est la facilité avec laquelle nous accédons à des développeurs-clé chez Ceetron, ainsi que la conception des API 3D Components qui proposent le niveau d’abstraction idéal pour un programmeur Python. Ceetron a une panoplie très riche de lecture de bases de résultats, et il n’y a pas de limite à ce qu’on peut faire en matière de visualisation avec 3D Components. De plus, l’intégration avec des toolkits GUI standards comme PyQt rend le développement très fluide, modulaire et intuitif. Et, bien entendu, je partage l’enthousiasme d’Andres pour Python comme langage de post-process en ingénierie – c’est bien pour ça que nous ne développons exclusivement qu’en Python ! »

Nous tenterons de vous proposer prochainement une entrevue plus approfondie et technique de Tim, lors d’un prochain post sur ce blog.

N’hésitez pas à nous contacter si vous souhaitez en apprendre plus sur l’utilisation de Python avec nos toolkits de programmation.

Andres
Senior Developer
andres.rodriguez-villa@ceetron.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s