Reading Time: 13 minutes

tl;dr

La visualisation in situ traite et analyse les données de simulation pendant que la simulation s’exécute, directement en mémoire, au lieu d’écrire des résultats bruts sur le disque pour un post-traitement ultérieur. Cette approche est essentielle pour le calcul exascale où la bande passante d’E/S ne peut pas suivre la génération de données. En intégrant la visualisation pendant le calcul, vous pouvez :

  • Évitez les goulots d’étranglement d’E/S qui paralysent les flux de travail traditionnels
  • Surveiller les simulations en temps réel et diriger les paramètres à la volée
  • Réduire les besoins de stockage par ordre de grandeur
  • Capturez des phénomènes transitoires qui seraient manqués avec des instantanés peu fréquents

Le compromis est une complexité supplémentaire et une contention des ressources. Vous devez décider quoi visualiser avant l’exécution, et la visualisation est en concurrence avec la simulation pour les cycles CPU/GPU.

Introduction : Pourquoi la visualisation in situ est importante

Les simulations scientifiques génèrent de grandes quantités de données. Une seule exécution Exascale peut produire des pétaoctets de sortie, mais l’écriture de ces données sur le disque devient un goulot d’étranglement fondamental : les systèmes de stockage ne peuvent pas suivre le rythme du débit de calcul. Le résultat est un écart croissant entre la rapidité avec laquelle les simulations peuvent produire des données et la rapidité avec laquelle ces données peuvent être sauvegardées et analysées.

La visualisation in situ (latin pour « en place ») aborde ce problème en effectuant des tâches de visualisation et d’analyse en même temps que la simulation, en accédant aux données directement de la mémoire avant d’être écrites sur le disque. Ce paradigme déplace le flux de travail de :

Simulation → Storage → Visualization

à :

Simulation + Visualization → Storage of images/reduced data

À mesure que le calcul à haute performance (HPC) s’étend vers l’échelle exascale, les techniques in situ ne sont plus facultatives – elles deviennent une nécessité pour la découverte scientifique. Ce guide explique comment fonctionne la visualisation in situ, la compare aux outils traditionnels de post-traitement et fournit des conseils pratiques et fournit des conseils pratiques pour l’adopter dans vos projets de recherche.

Comment fonctionne la visualisation in situ : le flux de travail de base

La visualisation in situ exploite les mêmes ressources de calcul qui exécutent la simulation pour effectuer une analyse visuelle. Il existe deux principales stratégies de couplage :

Visualisation in situ étroitement couplée (en ligne)

Le code de visualisation partage le même espace mémoire et exécutable que la simulation. À des intervalles spécifiés (par exemple, à chaque pas de temps ou lorsque certains critères sont remplis), la simulation interrompt, les données sont transmises à des algorithmes de visualisation et des images ou des données dérivées sont produites.

Pros :

  • Latence la plus faible Accès aux données de simulation
  • Pas de surcharge de communication réseau
  • Mappage de données le plus simple (même disposition de mémoire)

Contre :

  • La visualisation est en concurrence directe pour les cycles CPU/GPU, ralentissant la simulation
  • Augmentation de l’empreinte mémoire par nœud
  • Un plantage dans le code de visualisation peut planter toute la simulation

Exemple d’outils : Paraview Catalyst intégré directement dans le binaire de simulation.

Visualisation in situ (en transit) faiblement couplée (en transit)

La simulation s’exécute sur un ensemble de nœuds de calcul, tandis que la visualisation s’exécute sur un ensemble de nœuds distinct et co-alloué. Les données sont transférées sur le réseau (souvent via MPI) vers les processus de visualisation.

Pros :

  • La visualisation n’interfère pas directement avec le calcul de la simulation
  • Peut mettre à l’échelle la visualisation de manière indépendante
  • Meilleure isolation des pannes

Contre :

  • Frais de transfert réseau
  • Nécessite plus de ressources totales (noeuds séparés)
  • Les données peuvent être reparties pour la visualisation

Exemple de frameworks : Damaris, qui utilise des cœurs dédiés pour l’analyse asynchrone.

Approches hybrides

De nombreux déploiements dans le monde réel utilisent une stratégie hybride : étroitement couplée au sein d’un nœud (en utilisant le même CPU/GPU) mais vaguement couplée entre les nœuds, ou en utilisant des pipelines asynchrones où la visualisation s’exécute avant la simulation sur les mêmes ressources.

In-situ vs post-traitement : une analyse comparative

Fonctionnalité Visualisation in situ Visualisation post-traitement
Temps En temps réel, lors de la simulation Retardé (après simulation)
Flux de données Traiter les données en mémoire Écrit les données sur le disque, puis les lit
Frais généraux d’E/S Très faible (réduit les écritures sur disque) Très élevé (goulot d’étranglement du disque)
Besoins de stockage Faible (seulement les images/résumés enregistrés) Extrêmement élevé (données brutes complètes)
Résolution temporelle Élevé (à chaque pas de temps possible) Faible (limité par la capacité de stockage)
Flexibilité Faible (décisions fixées avant l’exécution) Élevé (peut réanalyser les données enregistrées)
Impact de calcul Partage des ressources avec la simulation Aucun impact sur l’exécution de la simulation

Quand utiliser la visualisation in situ

  • Simulations Exascale où la bande passante d’E/S est le facteur limitant
  • Phénomènes transitoires nécessitant une fidélité temporelle élevée (p. ex., fronts à mouvement rapide, turbulence)
  • Débogage : vous devez intercepter les erreurs avant de perdre des millions d’heures de base
  • Simulation direction : vous souhaitez ajuster les paramètres à la volée en fonction des résultats intermédiaires
  • Réduction des données : vous devez extraire des fonctionnalités, des statistiques ou des images et supprimer les données brutes

Quand le post-traitement a toujours du sens

  • Ensembles de données petits à modérés qui peuvent être stockés à un prix abordable
  • Analyse exploratoire où vous devez essayer de nombreuses techniques de visualisation différentes après coup
  • Rendu haute fidélité qui nécessite le jeu de données complet et ne peut pas être fait avec des représentations réduites
  • Objectifs d’archives—Préservation des données brutes pour la reproductibilité future

En pratique, de nombreuses équipes adoptent une stratégie hybride : utilisez in situ pour produire des ensembles de données réduits (par exemple, bases de données de cinéma, statistiques, isosurfaces) et conserver juste assez de données brutes pour certaines étapes de temps, puis effectuer un post-traitement détaillé sur l’ensemble réduit.

Outils et frameworks populaires pour la visualisation in situ

Plusieurs cadres open-source matures prennent en charge l’intégration in situ :

Catalyseur Paraview

Paraview Catalyst est une bibliothèque légère qui permet une analyse in situ à l’aide du pipeline VTK. Il fournit une petite API que les simulations en C++, C, Fortran ou Python peuvent appeler pour transmettre des données aux algorithmes de visualisation de Paraview. Catalyst peut générer des images, extraire des fonctionnalités ou produire des bases de données cinéma pour une exploration ultérieure.

Principales forces :

  • Exploit la pleine puissance de VTK et Paraview
  • Prend en charge les modes étroitement et lâchement couplés
  • Développement actif et documentation complète

Ressources :

Visitez Libsim

Visit propose libsim, un ensemble de bibliothèques qui permettent aux simulations de se connecter au moteur de visualisation de Visit. Comme Catalyst, il prend en charge les modes en ligne et en transit. La visite est particulièrement forte pour la visualisation parallèle à grande échelle et a été utilisée sur de nombreux systèmes de classe de leadership.

Principales forces :

  • Très évolutif pour des centaines de milliers de cœurs
  • Un riche ensemble d’opérateurs de visualisation
  • Forte prise en charge des données de raffinement de maillage adaptatif (AMR)

Ressources :

Ascension

Ascent est une bibliothèque in situ légère et multicœur conçue pour les environnements à ressources limitées. Il est particulièrement efficace pour les applications accélérées par GPU et peut fonctionner efficacement sur un petit sous-ensemble de nœuds.

Principales forces :

  • Frais généraux minimes
  • Bonne prise en charge du GPU
  • Une partie du projet informatique américain Exascale

damaris

Damaris se concentre sur l’utilisation de cœurs dédiés pour l’analyse in situ asynchrone, isolant la visualisation de la simulation principale afin de minimiser l’impact sur les performances. Il prend en charge les backends Visit et Paraview.

Principales forces :

  • L’exécution asynchrone réduit les interférences de simulation
  • Gère le mouvement et la répartition des données
  • Convient pour les simulations à long terme en régime permanent

Sensei et conduit

Sensei fournit une interface générique qui découpe les simulations à partir d’outils in situ spécifiques. Conduit gère la description et l’échange de données. Cette abstraction permet au même code de simulation de fonctionner avec Catalyst, Ascent ou d’autres backends sans changement de code.

Quand choisir : si vous souhaitez éviter le verrouillage des fournisseurs et prendre en charge plusieurs frameworks in situ.

Défis de mise en œuvre : ce qui peut mal tourner

L’intégration de la visualisation in situ dans une base de code de simulation existante n’est pas triviale. Préparez-vous à ces défis communs :

Contention des ressources et overhead de performances

La visualisation consomme des cycles de CPU, du temps du GPU et de la mémoire qui seraient autrement disponibles pour la simulation. Des études ont montré que les pipelines in situ mal optimisés peuvent ralentir les simulations de 20 à 50 % ou plus. La clé est de mesure et de liant les frais généraux.

Stratégies d’atténuation :

  • Utilisez des modes asynchrones ou en transit pour séparer les ressources
  • Limiter la fréquence de visualisation (par exemple, tous les 10e pas de temps)
  • Utiliser des algorithmes de réduction des données pour réduire le volume de traitement
  • Dédier un sous-ensemble de cœurs/GPU exclusivement à la visualisation

Empreinte mémoire

Le chargement des bibliothèques de visualisation à côté de la simulation augmente l’utilisation de la mémoire par nœud. Sur les systèmes liés à la mémoire, cela peut forcer une réduction de la taille du problème par nœud.

Atténuation :

  • Choisissez des cadres légers (Ascent est conçu pour cela)
  • Libérez la mémoire de visualisation rapidement après utilisation
  • Considérez les modes de transit où la visualisation s’exécute sur des nœuds distincts

Conversion et interopérabilité des données

Les codes de simulation utilisent souvent des structures de données personnalisées optimisées pour les solveurs PDE. Des outils in situ comme VTK attendent des données dans des formats spécifiques (par exemple, grilles structurées, maillages non structurés). L’écriture d’adaptateurs pour traduire entre ces représentations peut être complexe et peut impliquer des copies approfondies coûteuses.

Solution :

  • Utilisez des couches d’abstraction comme Sensei/Conduit pour définir un modèle de données commun
  • Explorez les interfaces zéro copie si votre simulation et votre visualisation partagent la même disposition sous-jacente
  • Facteur Adapter le code dans un module distinct pour isoler la complexité

Évolutivité parallèle

Les algorithmes de visualisation doivent évoluer à la même taille que la simulation (potentiellement des millions de rangs MPI). Des opérations globales telles que le rendu volumique ou l’extraction d’isossurface dans toutes les données peuvent devenir des goulots de communication.

Solution :

  • Utilisez des algorithmes de visualisation distribuée qui minimisent la communication entre les nœuds
  • Utiliser la réduction des données ou l’échantillonnage pour réduire le volume de données effectif
  • Envisager des approches hiérarchiques : analyse locale d’abord, puis résultats agrégés

Le problème « a priori »

La visualisation in situ vous oblige à décider avant la course ce qu’il faut visualiser. Si vous réalisez plus tard que vous deviez examiner une variable différente ou appliquer un filtre différent, les données brutes ont disparu. Il s’agit de la rigidité fondamentale de l’In-Situ.

Contournement :

  • Enregistrer un ensemble de données réduit mais flexible (par exemple, une base de données cinématographique) qui prend en charge le rétablissement ultérieur à partir de différents points de vue
  • Enregistrez périodiquement de petits instantanés de données brutes à des pas de temps clés
  • Utilisez la direction de la simulation pour ajuster dynamiquement les paramètres de visualisation au fur et à mesure de l’exécution

Complexité et fragilité du code

Un couplage serré signifie que la bibliothèque de visualisation devient une partie de l’exécutable de simulation. Un bogue dans le code de visualisation peut planter toute la simulation. L’intégration augmente également la complexité du code et la charge de maintenance.

Meilleures pratiques :

  • Encapsuler tous les appels in situ derrière une interface propre
  • Gardez le code de visualisation séparé des principaux solveurs
  • Fournir une configuration d’exécution pour activer/désactiver facilement
  • Test avec la visualisation désactivée pour assurer la stabilité de la simulation

Meilleures pratiques pour une adoption in situ réussie

Sur la base de l’expérience de la communauté HPC, suivez ces directives pour maximiser le succès :

1. Commencez par un prototype

Avant de s’engager dans une intégration complète, créez un petit prototype qui exerce le pipeline de base : Simulation → Outil in situ → Image de sortie. Cela valide la chaîne d’outils et révèle les obstacles d’intégration au début.

2. Adoptez des architectures asynchrones ou hybrides

Évitez les modes étroitement couplés à moins que vous n’ayez des preuves solides que les frais généraux seront acceptables. Préférez les approches en transit ou asynchrones où la visualisation s’exécute sur des cœurs ou des nœuds dédiés. Cela isole les interférences de performances.

3. Définir des objectifs clairs de réduction des données

In-situ est plus efficace lorsque vous réduisez les données avant de les sauvegarder. Décidez d’avance :

  • De quelles images ou films avez-vous besoin ?
  • Quelles quantités dérivées (par exemple, flux intégrés, valeurs maximales) sont essentielles ?
  • Pouvez-vous utiliser des bases de données de cinéma pour une exploration post-hoc flexible ?

4. Mesurez tout

Instruisez votre code pour mesurer :

  • Temps de simulation avec et sans activé in situ
  • Utilisation de la mémoire par nœud
  • Fréquence et durée des pauses de visualisation
  • Qualité et utilité des produits produits

Sans mesures, vous ne pouvez pas dire si in situ aide ou fait mal.

5. Tirer parti de l’infrastructure existante

Ne réinventez pas la roue. Utilisez des cadres établis (Catalyst, Ascent, Damaris) plutôt que d’écrire du code in situ personnalisé à partir de zéro. Ils gèrent de nombreux détails de bas niveau (communication MPI, répartition des données, cellules fantômes) susceptibles d’être implémentées.

6. Plan de pilotage de simulation

Si vous souhaitez diriger des simulations de manière interactive, concevez votre pipeline in situ pour accepter les messages de contrôle externes. Des outils comme Icarus (pour Paraview) offrent des capacités de pilotage avec des changements de code minimes.

7. Utilisez des cellules fantômes pour des limites parallèles

Lorsque votre domaine de simulation est décomposé entre les rangs MPI, les algorithmes de visualisation qui nécessitent des données de voisinage (par exemple, des gradients, des isosurfaces) doivent communiquer au-delà des frontières du sous-domaine. Précalculer et stocker des « cellules fantômes » pour éviter les communications répétées lors de la visualisation.

8. Gardez la visualisation facultative

Enveloppez tous les appels in situ derrière un indicateur d’exécution. La simulation doit fonctionner normalement avec in situ désactivé. Ceci est essentiel pour le débogage et pour les scénarios où vous souhaitez exécuter sans les frais généraux.

Applications du monde réel : où brille in situ

La visualisation in situ est devenue indispensable dans plusieurs domaines scientifiques :

Dynamique des fluides computationnelle (CFD)

Les simulations d’écoulement turbulent génèrent des champs 3D massifs de vitesse et de pression. La visualisation in situ peut extraire des tranches 2D, des lignes de courant ou des cœurs Vortex en temps réel, permettant aux ingénieurs de surveiller la séparation des flux, les ondes de choc ou l’instabilité de la combustion au fur et à mesure de leur développement.

Astrophysique et cosmologie

Les simulations cosmologiques avec Adaptive Mesh Refinement (AMR) suivent les halos de matière noire et les densités de gaz sur des milliards d’années. L’analyse in situ identifie les halos, classe les structures et suit les fusions à haute résolution temporelle, des tâches qui seraient impossibles avec des instantanés enregistrés peu fréquents.

Dynamique moléculaire et science des matériaux

Les ensembles d’exécutions de dynamiques moléculaires peuvent être surveillés in situ pour détecter des événements rares tels que la nucléation, les transitions de phase ou la nucléation de luxation. Les chercheurs peuvent arrêter les simulations tôt lorsqu’un événement se produit, économisant des ressources de calcul.

Météo et informatique urgente

Les prévisions météorologiques d’ensemble pour les ouragans ou les incendies de forêt nécessitent l’exécution de dizaines de simulations en parallèle. L’analyse topologique in situ identifie le résultat le plus probable de l’ensemble, fournissant des informations essentielles pour les décisions d’urgence avant que l’ensemble de données complet ne soit écrit.

Visualisation des performances

Ironiquement, des techniques in situ sont également utilisées pour visualiser les performances du système HPC lui-même, en surveillant la bande passante de la mémoire, les modèles de communication et l’équilibre de charge lors de l’exécution pour guider l’optimisation.

Mise en route : une liste de contrôle pratique

Si vous envisagez d’ajouter une visualisation in situ à votre code de simulation, suivez ce plan étape par étape :

Phase 1 : évaluation (1 à 2 semaines)

  • [ ] Quantifiez votre problème d’E/S : combien de données génèrez-vous ? Combien de temps dure l’écriture ? La réduction de la production permettrait-elle de gagner beaucoup de temps ?
  • [ ] Identifier les objectifs de visualisation : de quelles images ou analyses spécifiques avez-vous besoin pendant la course ? (par exemple, « 2d tranche de température toutes les 100 étapes », « pression maximale dans le temps »)
  • [ ] Outils d’enquête : passez en revue Paraview Catalyst, visitez libsim, Ascent et Damaris. Qu’est-ce qui correspond à votre langage de programmation et à votre environnement HPC ?
  • [ ] Vérifier la prise en charge du système : votre centre de supercomputation prend-il en charge les flux de travail in situ ? Les bibliothèques requises sont-elles installées ?

Phase 2 : prototype (2 à 4 semaines)

  • [ ] Mettre en place un exemple minimal : prenez un petit cas de test (par exemple, un simple solveur d’équations de chaleur) et intégrez le cadre in situ choisi pour produire une seule image.
  • [ ] Mesure de base de la ligne de base : comparez le temps d’exécution de la simulation avec et sans activé in situ. Les frais généraux sont-ils acceptables (< ; 10 à 15 %) ?
  • [ ] Testez la réduction des données : expérimentez avec différentes stratégies de réduction (sous-échantillonnage, isosurfaces, agrégats statistiques). La production répond-elle à vos besoins scientifiques ?
  • [ ] Vérifier l’évolutivité : exécutez le prototype sur 1, 10, 100 rangs. L’échelle aérienne s’adapte-t-elle de manière linéaire ou explose-t-elle à plus grande échelle ?

Phase 3 : Intégration (4 à 8 semaines)

  • [ ] Design d’une couche d’abstraction : créez un module qui encapsule tous les appels in situ derrière une simple API (par exemple, beginTimestep(), addData(field), execute(), endTimestep()). Cela facilite l’échange de frameworks ultérieurement.
  • [ ] Ajouter une configuration : utilisez des indicateurs d’exécution ou des variables d’environnement pour contrôler la fréquence in situ, les formats de sortie et les variables à capturer.
  • [ ] Mise en œuvre d’une dégradation gracieuse : assurez-vous que la simulation se poursuit même en cas d’échec in situ (par exemple, écrivez un avertissement mais n’interrompez pas).
  • [ ] Intégrer avec les E/S existantes : décidez comment les sorties in situ (images, bases de données) coexisteront avec tous les vidages de données de post-traitement existants.
  • [ ] Ajouter une direction si nécessaire : si la direction interactive est un objectif, implémentez des rappels ou des messages de transmission pour autoriser les changements de paramètres externes.

Phase 4 : Validation et production (2 à 4 semaines)

  • [ ] Exécutez des tests de bout en bout : exécutez une simulation scientifique complète avec l’activation in situ. Vérifiez que les sorties sont correctes et que la simulation se termine dans un délai acceptable.
  • [ ] Test de contrainte : repoussez les limites : s’exécuter sur le nombre de cœurs complet prévu, avec une taille maximale du problème. Surveiller la mémoire, la communication et la stabilité.
  • [ ] Documenter le flux de travail : rédiger des instructions claires pour les utilisateurs : comment activer in situ, quelles options sont disponibles, où les sorties sont écrites, comment les interpréter.
  • [ ] Formez les utilisateurs : assurez-vous que les membres de l’équipe comprennent le flux de travail in situ et peuvent résoudre des problèmes courants.

Des pièges courants et comment les éviter

Piège Symptôme Prévention / Correction
Frais généraux illimités La simulation ralentit par > 30 % limiter la fréquence in situ ; utiliser en transit ; Profil pour trouver des goulots d’étranglement
Épuisement de mémoire Emplois tués par Oom Killer Réduire le volume de données transmis ; Utilisez moins de cœurs dédiés ; Passer en mode lâchement couplé
Variables manquantes Réalisez plus tard que vous deviez économiser la quantité x Enregistrez régulièrement de petits instantanés bruts ; Utilisez le format cinéma pour plus de flexibilité
Échelle médiocre Le temps sur place augmente avec le nombre de cœurs Utilisez des algorithmes de visualisation distribuée ; données de répartition; Agréger localement en premier
Simulation des plantages de la visualisation Un mauvais appel de visualisation interrompt toute la course Enveloppez les appels in situ dans try-catch ; Désactiver in situ en cas d’échec ; Gardez le code de simulation séparé
Les fichiers de sortie s’écrasent Plusieurs exécutions écrivent sur les mêmes images Inclure les horodatages ou les ID de travaux dans les noms de fichiers de sortie ; Utiliser des répertoires de sortie distincts

Conclusion : la visualisation in situ vous convient-elle ?

La visualisation in situ est un puissant paradigme pour lutter contre le déluge de données du calcul scientifique moderne. En traitant les données en mémoire pendant les cycles de simulation, vous pouvez surmonter les goulots d’étranglement des E/S, réduire les coûts de stockage et obtenir des informations en temps réel sur vos modèles. Cependant, ce n’est pas une solution miracle : il introduit de la complexité, nécessite des décisions de conception initiales et peut avoir un impact sur les performances de la simulation si elle est mal implémentée.

Pour les groupes de recherche exécutant des simulations PDE à grande échelle sur des systèmes HPC, en particulier ceux qui s’approchent d’Exascale, l’apprentissage et l’adoption de techniques in situ sont de plus en plus essentiels. Commencez petit avec un prototype, mesurez rigoureusement et augmentez délibérément. L’investissement est payant dans des cycles d’itération plus rapides, des informations scientifiques plus riches et la possibilité d’exécuter des simulations qui seraient autrement impossibles en raison du volume des données.

Guides connexes

Prochaines étapes

Prêt à essayer la visualisation in situ ? Commencez par :

  1. Évaluation de vos goulots d’étranglement d’E/S actuels : exécutez un outil de profilage (par exemple, Darshan) sur une simulation existante pour quantifier le temps passé à écrire des données.
  2. Installation de Paraview Catalyst ou Ascent sur votre système de développement et exécution des didacticiels.
  3. Créer un prototype minimal avec un simple cas de test pour mesurer les frais généraux et valider la chaîne d’outils.
  4. Attraction à l’équipe d’assistance HPC de votre établissement : ils ont souvent une expertise et des exemples de codes pour vous aider à démarrer.

Si vous avez besoin d’aide pour intégrer la visualisation in situ dans votre logiciel de recherche, contactez-nous pour une consultation et une formation adaptées aux équipes de calcul scientifique.