(08.06.2020) Antibes, France

On ne peut s’en empêcher. Chez Ceetron, dès que nous avons fini un SDK (kit de développement), nous nous en servons pour nos propres applications, quelque chose comme une loi de la Nature. Cette fois-ci, il s’agit de l’obscur DataProvider Framework – les développeurs me disent que même si ça ressemble à un SDK, ce n’en est pas un ?!. Ces lignes de code définissent une interface précise qui permet à nos partenaires d’écrire du logiciel personnalisé pour nourrir leurs visualisations. Mais, c’est un reader me direz-vous ? Pas tout à fait… les données (maillages et résultats) peuvent parfaitement venir d’un fichier, mais le DataProvider Framework permet également de fournir des données en cours d’exécution, depuis la mémoire (pensez à un solver qui calcule et envoie les infos sans passer par un fichier…)

Peu importe, ce n’est absolument pas le propos de ce blog. Luis – notre dernière recrue phare du bureau de Sophia Antipolis – a montré tout son talent d’optimisation quand on lui a demandé de développer un DataProvider qui lit des fichiers openFOAM. Nos SDK supportaient déjà ce format comme la plupart des formats standard du marché, mais nous n’étions pas trop éblouis par la performance bien qu’étant déjà au niveau de Paraview (le post-processeur naturel pour openFOAM). Et, détail supplémentaire, nos amis de chez Simscale partagaient cette frustration.

C’est là qu’est intervenu Luis. Quelques semaines de dur labeur et de quantités indécentes de café prises à des heures encore plus indécentes…et voilà : résultats spectaculaires.

Un rapport détaillé montre le gain de performance.

D’abord, merci à PiQ2 pour les modèles de test qu’ils nous ont fournis.

Le premier jeu de tests est réalisé sur un maillage de plus de 1 million de nœuds et presque 1 million d’éléments. Nous avons comparé le temps de chargement des résultats sur tout le modèle ainsi qu’en incluant un isovolume, et en générant une animation du remplissage du moule. Au fait, la « figure » ci-dessus est un modèle 3D interactif, n’hésitez à l’inspecter de plus près ou voir d’autres exemples sur le portail qui l’héberge.

Le reader de Ceetron est deux à trois fois plus rapide que Paraview sur chacun de ces tests. L’utilisation de la mémoire est également réduite, en particulier pour l’animation (3 fois moins de mémoire)

Sur un second modèle confidentiel de PiQ2 (env. 700 mille nœuds et 500 mille éléments), nous observons les mêmes rapports – le chargement d’un incrément est 2 à 3 fois plus rapide tout en utilisant en moyenne 25% de mémoire en moins.

Enfin, Luis a mis son code source à l’épreuve sur un modèle plus conséquent – merci à Simscale pour celui-ci.

Le bestiau a plus de 15 millions de nœuds pour plus de 12 millions d’éléments. Mais ce n’est pas tout : le modèle compte pas moins de 882 objets différents. Ici, nous nous sommes intéressés au temps qui passe entre le moment où vous cliquez « Ouvrir » et le moment où le modèle apparaît à l’écran. La figure qui suit résume les mesures : lecture du maillage environ 2x plus rapide et chargement du résultat 10x plus rapide. Spectaculaire est le mot juste. Bip ! Bip !

Bien sûr, le nombre de tests et de modèles est limité mais ce que nous avons observé a été cohérent tout au long de la phase de développement. Et bien sûr, une évaluation étendue du DataProvider ne peut pas faire de mal. Même si les performances sont impressionnantes, tous les développeurs savent que la guerre n’est jamais gagnée de manière définitive. Nous invitons nos partenaires et nos prospects à continuer à faire ce qu’ils font de mieux : nous harceler sur la performance… on adore ça !

Servez-vous et profitez : téléchargement des DataProvider Plugins 1.2.0 pour inclure le plugin dans votre application, ou testez-le directement avec une évaluation de Ceetron Analyzer Desktop

Bon codage à tous,

Andres, DCM