Rapport de Recherche. La visualisation distante. 4 rue Léonard de Vinci BP 6759 F Orléans Cedex 2 FRANCE.

Transcription

1 4 rue Léonard de Vinci BP 6759 F Orléans Cedex 2 FRANCE Rapport de Recherche La visualisation distante Sébastien Limet, Souley Madougou, Emmanuel Melin et Sophie Robert Université d'orléans LIFO Rapport N /12/2006 1/62

2 Étudedecomposantslogicielspourlavisualisationdistribuée hauteperformance Lotn 2:Étatdel'artsurlavisualisationdistante Rapportdesynthèsesurlessolutionsétudiées Préparépar Laboratoired'InformatiqueFondamentaled'Orléans(LIFO) ProjetParallélismeRéalitéVirtuelleetVérification(PRV) BâtIIIA,RueLéonarddeVinci BP OrléansCedex Rédigépour Commissariatàl'EnergieAtomique CEA/DIF/DSSI/SNEC CentreCEABruyères le Châtel 91680Bruyères le ChâtelCedex 2/62

3 Tabledesmatières I.Introduction... 4 II.Classificationenfonctiondulieudurendu Scénario1(Imagestreaming) VNC OpenGLVizserver HPRemoteGraphicsSoftware VirtualGLetlestravauxdel'UniversitédeStuttgart Scénario2(Rendulocal) RemoteDisplayX Approchedatastreaming Approchedatastreamingavecmulti résolution Scénario3(Approchesmixtes) Visapult PrototypeduSCIInstitute Universitédel'Utah VisualisationconcurrentedeAmes(NASAAmesResearchCenter) III.Modèlesdecommunications RéseausurlemodèleTCP/IP Approcheparcomposants CCM CCA Servicesweb Globus ApprocheFlowVR Descriptiongénérale ArchitectureFlowVR IV.Systèmesautonomes Amira Covise Approche Architecture EnSight Approche Architecture ParaView Descriptiongénérale Infrastructure VisIt Approche Architecture Covisa/CovisaG/gViz Covisa/CovisaG ProjetgViz:Intergicieldevisualisationpourlese Sciences Modèleencouches Miseenpratiquedumodèle /62

4 6.5 BibliothèquegViz DIVA SciRun/SciRun SciRun SciRun Mbender EncodeurJavascript QuickTimeVRobjectMovies Navigationinteractivedansdesimagespré renduesenmulti résolution CumulVS Approche Architecture EnvironnementpourlePilotagedeSimulationsNumériques Approche Architecture Cactus Modèle Parallélisme Visualisationdistanteetanalysededonnées V.Conclusion /62

5 I. Introduction Lavisualisationdedonnéesestdeplusenplusexploitéedansdenombreuxdomainesscientifiques (géologie, biochimie, mécanique,...). Son utilité ne s'arrête pas à l'illustration de résultats d'expériencesoudesimulationàdesfinsdevulgarisationmaiselledevientunélémentessentiel danslacompréhensiondephénomènesétudiésdanslesdifférentesdisciplinesscientifiques. Danstouslescas,faceauxenjeuxdelacomplexitédessimulationssous jacentesetdelatailledes données générées, le développement des applications scientifiques se base désormais sur des systèmes parallèles et distribués. Ainsi, il devient classique d'envisager un déploiement d'une applicationsurtroissitesparexemple.lepremierestencharged'exécuterlecodedelasimulation, ledeuxièmepermetlestockagedesdonnéesgénéréesouparamètresdelasimulationetenfinle derniersiteréalisel'affichagedesrésultats.cetétatdel'arts'intéresseàcedernierpoint.eneffet,la visualisation distante [18; 19] implique des contraintes particulières qui obligent à définir des solutionsspécifiquestenantcompteparexempledesbesoinsenfluiditédel'affichage. Nousnoussommesainsiintéressésàdifférentessolutionsdevisualisationdistanteafind'obtenir uneclassificationpermettantdejugerdeleurqualitéenfonctiondesattentesdesutilisateurs.il existeplusieursfaçonsdeclassifierlesdifférentessolutionsdevisualisationdistante.nousavons choisid'abordercetteclassificationenfonctiondulieudurenduquiinfluesurlesperformancesen termedetauxderafraîchissementdel'imageparrapportàlaqualitéduréseau.cepointdevue permetdetraiterlesdifférentesméthodespossiblespourrépartirlepipelinegraphiqueentreles deuxsitesimpliquésetd'envoirlesavantagesetlesinconvénients.ilferal'objetdelapremière partiedecedocument.ensuitelavisualisationdistantes'appuiesuruneinfrastructureréseaudont dépendentlesperformancesfinales.cetteinfrastructurepeutêtreunesimpleconnexiondetype socketous'appuyersurdesconceptsplusgénérauxquivisentàformaliserlesaspectsréseaupour desdéploiementsdetypegrid.cesaspectsferontl'objetdeladeuxièmepartiedecedocument. Cettepartienouspermettradedécriredifférentsmodèlesdecommunicationquiapportentouqui pourraient apporter à la visualisation distante un cadre de développement tout à fait pertinent. Enfin,ilexistedéjàaujourd'huidessystèmesquenousqualifionsd'autonomesdédiésdirectement ouindirectementàlavisualisationdistante.cessystèmesserontdécritsdanslatroisièmepartiede cerapport.ilsviendrontillustreràlafoislaclassificationselonlelieudurenduetlesdifférents modèlesdecommunicationpossibles.deplus,untableaugénéralviendrarésumerl'ensembledes systèmescitésenfonctiondesqualitésd'unesolutiondevisualisationdistantesoit: lesperformances(réseau,framerate), lesdépendancesmatériellesetlogicielles, lesdépendancesgraphiques lagénéralitéetleniveaudusystème(middleware,framework,...) lesmodalitésdedisponibilité(commerciales,opensource)etlestatutdedéveloppementet demaintenance l'évolutivitéetl'ouvertureversdesfonctionsplusavancées(collaboratif,steering) 5/62

6 II. Classificationenfonctiondulieudurendu Danscettepremièrepartie,ils'agitdedécriredessolutionsdevisualisationdistanteenfonctiondu lieud'exécutiondurendu.pourcelaonsupposequelesdonnéesinitialessontstockéessurune machinedistante(simplepc,grappeousupercalculateur)appeléeserveuretquel'affichageest effectuéàpartird'unedeuxièmemachineenlocal(ordinateurdebureau,grappepilotantunmur d'images,...)appeléeclient.danscecontexte,ilestpossiblededécrirel'ensembledesétapesqui précédentl'affichagesousformedupipelinedonnéfigure1 données brutes Simulation Stockagedes résultats pré rendu rendu Serveur Scénario 1 Serveur Affichage Net Net Client Client Scénario 2 Serveur Net Client Scénario 3 Figure1:Pipelinedelavisualisationdistanteetrépartitionclient/serveur(schémainspiréde[47]).«Net»désigne l'opérationdetransfertdesdonnéesentreleserveuretleclient. où l'étape«simulation»estfacultativeetdésignelescalculseffectuéssurlesdonnéesbrutes, l'étape«pré rendu»désigneunepartiedupipelinedevisualisationavecparexemplele calculdelagéométrie,etestcomplétéeparl'étape«rendu»(graphique). Danscecontextenousavonsretenutroisscénariossurlesquatrepossibles: 1. Scénario1:leserveureffectueentièrementlerenduetenvoiedesimagesauclientpour l'affichage.cettetechniqueestconnuesouslenomd'imagestreaming. 2. Scénario2:leserveureffectuelasimulationet envoielerésultatauclientquicalcule entièrementlerenduavantl'affichage. 3. Scénario3:ilyaunerépartitiondechargedesopérationsentreleserveurquieffectuele pré renduetleclientquiréaliselerendu. Ledernierscénarioconsisteraitàenvisagerleserveurcommeunsimplelieudestockage(basede données)avecunclientquieffectueentièrementlasimulation,lerenduetl'affichage.danslecadre d'uneétudesurlavisualisationdistante,nousconsidéronscescénariocommesimilaireauscénario 2oùlerenduesteffectuéenlocal. 6/62

7 1. Scénario1(Imagestreaming) Lebesoinenvisualisationdistantevientessentiellementdelanécessitédereporterdessimulations lourdesencalculsurdessitesspécialiséséquipésensupercalculateursouengrappes.lavolonté ensuitedevisualiserlesdonnéesgénéréessoitsuruneplate formelocaledevisualisationsoitmême sursapropremachinedebureauestnaturelle.lapremièreidéedanscecontexteestdeprofiterde la puissance de calcul distante pour également procéder au calcul de rendu pour n'envoyer à l'utilisateurqu'unfluxd'images(imagestreaming).cettetechniqueabiensûrcommeprincipal avantagedeneriendemanderdespécifiqueauposteclient.ellepermetégalementd'assurerla confidentialitédesdonnéesennefaisanttransitersurleréseauquedespixelsetnondesdonnées brutes.enrevancheleprincipalinconvénientdecetteméthodeestqu'ellesolliciteleréseaupour l'envoidesimagesrelativesàchaquechangementd'unparamètrelocaldevisualisation(pointde vue,...).mêmesilabandepassantedemandéen'estdépendantequedelarésolutionlocaleetnonde latailledesdonnéesoudelacomplexitédurendu,cesenvoisrépétéspeuventrestreindrelaqualité dutauxd'imagesàl'arrivée.danscescénario,lafluiditédurenduinteractifnécessiteunréseauà faiblelatence. Danscettesection,nousallonsdécriretroissolutionsd'imagestreaming(VNC,OpenGLVizserver et VirtualGL) qui font référence et sont très utilisées. Par exemple, VaPOR développé par le National Center for Atmospheric Research qui a pour ambition de proposer une plate forme d'analysesetdevisualisationdedonnéesfaitappelàvizserverpourl'aspectvisualisationdistante. Autreexemple,leprojetTACCdel'universitéduTexaspourlecalculscientifiques'appuiesur Maverickuneplate formelogicielleetmatériellededéploiementd'applicationsscientifiquesqui intégrevirtualgl/vncpourledéportdel'affichagesurunposteclient.lescentresdecalcul nationauxcinesetidrisutilisentvizserverdepuisdesannées,exploitantainsidesmachinesde puissancesgionyxauprofitd'utilisateursrépartissurtoutelafrance. 1.1 VNC VNCpourVirtualNetworkComputing[58]estunprotocoled'affichagedistants'appuyantsurle réseautcp/ip.lapremièreapplicationviséeestlebureauvirtuel.ils'agitdepermettreunaccèsà sonbureauàpartirden'importequelpostereliéàinternetviaunsimplenavigateurparexemple. VNCserveur ProtocoleVNC VNCviewer Figure2:Principedel'affichagedistantVNC Le protocole VNC estbasésur unearchitecture client/serveur avec unprotocole d'accès et de transfertduframebufferverslamachinelocaleselonunencodagenégociéentreleserveuretle 7/62

8 client.l'apportdevncsesitueàlafoissurlaconceptiond'unclientléger(viewer)(cffigure2)et surl'encodagedesdonnéesadaptéautypedelatransmission,soitunensembledefenêtres.les encodagespossiblessontentreautresl'encodageparcopiederectangles,adaptéauxmodifications detypeascenseurdansunefenêtre,etl'encodageséparantleszonesdubureauquicorrespondentau fondd'écranetleszonesquicorrespondentréellementàdesdonnées. Il s'agit donc d'une première approche de l'image streaming sachant que VNC est adapté à l'affichage du bureau d'un utilisateur, affichage qui ne nécessite pas une fréquence de rafraîchissement trop élevée. Par contre dans le cas de la visualisation scientifique, les performancesdeceprotocolepeuventêtreinsuffisantes. 1.2 OpenGLVizserver CettesolutionestunesolutioncommercialedéveloppéeparSiliconGraphics [57].Ellepermetà touttypedeclients(pc,portable,grappe)quelquesoitsonsystèmed'exploitation,d'accéderaux ressourcesd'unemachinegraphiquesgi(onyxousilicongraphicsprism)etd'afficherlerésultat surleclient.deuxmodesd'affichagesontdisponibles,soitparapplicationsoitlebureaucomplet. OpenGLVizserverestbaséesurunearchitectureclient/serveur,surlesbibliothèquesOpenGLet X11 associées à des wrappers et sur des bibliothèques supplémentaires qui vont permettre de complétercertainesfonctionsopengletx11pourlesopérationsdetransfertversleclient.le principe général est illustré par la figure 3. L'application OpenGL classique fonctionne sur le serveurenutilisantnonpaslesbibliothèqueslibgl.soetlibx11.sonativesmaislesbibliothèques «wrappées»d'openglvizserverquiagissentsurcertainesfonctionsopengl.labibliothèque libvsx.sopermetdegérerlesinformationsnécessairesàopenglvizserverpourletransfertdes imagesauclient. Serveur(ressourcesgraphiques) application OpenGL + wrappers Run time system + vssession Client(affichage) évènement framebuffer OpenGL vizserver client Segmémoirepartagée Figure3:Principed'OpenGLvizserver. Undeuxièmeprocessusvssessionalachargedecompresseretd'envoyercesdonnéesgrâceàun protocole entre libvsx.so et vssession basé sur le partage d'un segment de la mémoire. A la réception d'un événement par exemple de type swap buffer de la part du client, l'application OpenGLgèrelereadbackduframebufferetvssessioncompresseetenvoiel'imageadaptéeàla 8/62

9 résolutionduclient. Lesperformancesdépendentdestechniquesdecompressionutilisées(tauxdecompressionetcoût encpu)etbiensûrdelabandepassantedisponible.demanièregénéralesurunréseaulan100 Mbit,lesperformancessontdel'ordrede10à30fpsenfonctiondutauxdecompressionpourune résolution1280x HPRemoteGraphicsSoftware HPproposeégalementunesolutionlogicielleanalogueàOpenGLVizserverbaséesurdel'image streamingviadescommunicationsdetypetcp/ip [27].Lerendueffectuésurleserveurdistant s'appuiesurl'accélérationmatériellepourgénérerl'imagerésultantequiestcompresséeetenvoyée auclient. 1.4 VirtualGLetlestravauxdel'UniversitédeStuttgart LeprojetVIS(VisualizationandInteractiveSystems)del'universitédeStuttgartapourthèmede recherchelavisualisationscientifique,enparticulierlerenduvolumiqueetabordelaquestiondela visualisationdistantedansdifférentstravaux.lepremieraxederecherche[56]abordel'approche servicewebdelavisualisationdistanteetseradécritdanslapartie4decerapport. VIS s'intéresseavant tout àla visualisation3d.le deuxièmeaxe derecherche concerne donc l'utilisationdurendubasésurdel'accélérationmatériellepourobtenirunframeratecorrect,même sil'affichagen'estpasréalisésurlesiteoùs'effectuelescalculs.ainsiceprojetabordelerendu distantselonlescénario1.leurapprocheestdepermettreàtouteapplicationbaséesuropenglet GLXd'êtreutiliséesurdeuxsitesdistantssansaucunemodificationducode.Elleaétéimplémentée (pardesdéveloppeursinconnus)souslenomdevirtualgl,disponibleenopensource. a) Descriptiongénérale UneapplicationOpenGL/GLXpeutfonctionnerenmodedirectcommel'illustrelafigure 4.Ce modeappelé«directrendering»permetauxcommandesopengld'êtreadresséesdirectementàla cartegraphiquesanspasserparleserveurx.pourlemomentcemodeestobligatoirelorsqu'on souhaiteutiliserl'accélérationmatérielledelacartegraphiqueduserveur.cependant,danscecas, l'affichagesurunsitedistantdel'imagerésultanten'estpasimmédiatetnepeututiliserledéportde l'affichage. Application Xlib ÉvénementX Serveur X CommandeX libgl GLX OpenGL Carte graphique Figure4:LemodedirectpourOpenGL/GLX 9/62

10 LestravauxdeVIS [52] consistentàutiliserlemodedirectassociéàdel'imagestreamingpour transmettre l'image au client pour affichage. En profitant des propriétés d'une édition de liens dynamique,leursolutionpermetsansaucunemodificationdeprocéderàdelavisualisationdistante àpartirdetouteapplicationécriteenopengletglx,quifonctionneenlocal. L'architecture finale est basée sur le développement d'une bibliothèque supplémentaire à GLX (appeléeiciglx+)quivapermettreletraitementparticulierdecertainesfonctionsglxafinde transmettrel'imageauclient.parexemple,àl'appeldelafonctionglxswapbuffers,letraitement consistera à lire le framebuffer puis à transmettre l'image résultante au client via la méthode XputImageouXshmPutImage.Lapremièresolutionproposéerépondàl'architectureillustréeparla figure5. Cettearchitectureaétéaméliorée[53;54]afind'intégrerplusfacilementdesoutilsdecompression adaptésàl'application.ainsiaprèslectureduframebuffer,l'imageestcompresséeetenvoyéeau client.alaréceptiondel'imageparleclient,elleestdécompresséeettraitéeparsonserveurx. SeulleserveurXduserveurdoitreconnaîtreGLX. b) VirtualGL CettedernièrearchitectureaétédéveloppéesouslenomdeVirtualGLenopensource [49].Le serveur utilise la bibliothèque appelée GLX+ dans ce rapport et le client est constitué principalementd'undémonenécoute.cedernier,àlaréceptiondedonnées,lesdécompresseet reconstituelespixelsdanslafenêtrexvoulueavanttraitementparleserveurx. Application OpenGL/GLX GLX+ GLX OpenGL Lect.Framebuffer OpenGL/ GLX/XLib ServeurX Événement Image ServeurX Affichage/Interaction Client Cartegraphique Serveur Figure 5 : Architecture OpenGL/GLX en mode direct avec image streaming Ilestégalementpossible,àpartirdumodedirect,d'utiliserunproxyXquivaprendreenchargela réceptiondescommandesetdesévènementsxmaiségalementlacompressionetl'envoidel'image résultante. VirtualGL propose donc une architecture supplémentaire qui intègre la bibliothèque GLX+pourutiliserl'accélérationmatériellemaisVNCcommeproxyafindegérerladétectiondes changementsd'affichage,lacompressionetl'envoidesimages.leclientdoitalorsêtreunclient VNC tel que décrit à la section 1.2. En terme de performances, il est en revanche préférable d'utiliserlasolutionsansproxyàcelleavecvnccarcedernierprotocoleestsurtoutadaptéaux 10/62

11 applications2ddetypebureau(donnéesmajoritairementstatiquesavecdegrandsblocsdemême couleur). 2. Scénario2(Rendulocal) De manière symétriqueauscénarioprécédent,certainessolutions devisualisationdistante sont baséessurunrenduenlocal.lescommandesgraphiquessontalorsenvoyéesauclientdontles ressources (la carte graphique essentiellement) doivent être suffisantes pour assurer le rendu correspondant.l'avantagedecettefamilledesolutionsestuneutilisationmoinsfréquentedela ressourceréseau.eneffet,tantquelesdonnéesnesontpasmodifiées,l'utilisateurpeutinteragir avecl'affichagesansdemanderdenouvellescommunications.cependant,lescommunicationssous jacentespeuvents'avérertrèsvolumineusesetsurtoutbeaucoupmoinsmaîtriséesquedanslecasde l'imagestreamingoùlesdonnéesenvoyéessontdespixelsdontlenombredépenduniquementdela résolutionduclient. Endehorsdel'approchebrute,lessolutionsquenousallonsdécriresontbaséessurdestechniques demulti résolutionsquipermettentdes'adapteràlabandepassantedisponibletoutenassurantun affichagecontinudesdonnées. 2.1 RemoteDisplayX Lasolutionlaplussimplepourprocéderàl'affichagesurunsitedistantestd'utiliseruneconnexion distanteauserveurdecalculs(sshparexemple)puisd'exporterl'affichagesurlamachinelocale. Cartegraphique Application ClientX Serveur Requêtes d'affichage ServeurX Client Figure6:PrincipeduRemoteDisplay AtraversleprotocoleX11touteslesrequêtesd'affichagesontalorsenvoyéesviaTCP/IPauserveur Xduclientselonl'architecturedonnéefigure6.Lesimagessontdoncbiencalculéesenlocaletce sontlescommandesgraphiquesquitransitentsurleréseau.x11estuneapi2d,leprotocolepeut toutefoisvéhiculerdesordres3dcomprisparuneextensiondetypeopengl. 11/62

12 Application ÉvénementX Xlib CommandeX libgl OpenGL OpenGL/GLX Serveur X Carte graphique Figure7:Lemodeindirectd'OpenGL PourlesapplicationsOpenGL,onretrouveceprincipedanslemodeappelémodeindirectoules commandes OpenGL issues du serveur, qui exécute l'application, sont transmises à la carte graphiqueduclientviasonserveurxcommelemontrelafigure Approchedatastreaming Ladeuxièmeapprochedevisualisationdistanterespectantlescénario2,s'appuiesurunlogicielde visualisationexécutésurleclientquicommuniqueavecleserveurcontenantlesdonnéesàafficher. Cette communication peut être de deux types. Soit l'écriture des résultats est effectuée sur un système de fichiers basé sur un montage réseau de type NFS soit les résultats sont transmis explicitement au logiciel de visualisation. Par exemple dans [22], le code GTC (Gyrokinetic ToroidalCode)fournitdesrésultatsécritsdansdesfichiersauformatHDF5.Leclientexécute AVS/ExpressoùExpressaétéenrichid'unefonctiondecommunicationsparsocket.Cettedernière permetàavs/express derecevoirlesdonnéesàafficher,soitlefichierhdf5souhaité,etde calculerlerenducorrespondantpourl'affichage.cependant,lorsquelesdonnéesàvisualisersontde grandetaille,lecodequilesgénèrepeutêtreparallèle.danscecas,ilestintéressantsoitdefaire appelàdessystèmesdefichiersparallèlesetdistribuéscommepvfs[44]ougpfssoitd'organiser une fusion des résultats du serveur vers le client. Là encore, [22] ou [32] proposent d'utiliser GridFTP [23] quifaitpartiedutoolkitglobus.parexemple, [22] associeàchaqueprocesseur générantdesdonnéesunthreadsupplémentairepourlesopérationsdesortiequiconsisteenune lecture d'un buffermémoire allouéàl'application. Cesthreads sontenchargedutransfert des donnéesenblocssuccessifsversleservicegridftpduclient.ilsgèrentégalementdesreprisesde transmissionencasdepertesdedonnées. Leprincipalinconvénientdecesapprochesestd'êtredépendantdelaqualitédelabandepassante duréseauutilisé.eneffet,laquantitédedonnéesàtransmettrepoureffectuerlatransmissiondes données à visualiser peut être conséquente. En cas de données variant dans le temps, cette transmissionpeutdevenirprohibitivepourpermettreunaffichagedequalité. 2.3 Approchedatastreamingavecmulti résolution Cetteapprocheapourobjectifderemédierauxinconvénientsdudatastreamingbrutenajoutantun 12/62

13 nouvelélémentdansl'architectureentrelasourcededonnéesetlesitedevisualisation.lerôlede cetélémentestd'élagueretdesimplifierlesdonnéesprovenantdelasourcededonnéesversle client d'affichage. Dans [39] par exemple le serveur intermédiaire, appelé serveur de données, effectuedessimplificationsenutilisantdestechniquesdemulti résolution.l'idéeexploitéedans cetteapprocheestdeconsidérerquel'explorationdesdonnéescomportedesphasesdenavigation durantlesquellesl'utilisateurrecherchelapartiedesdonnéesquil'intéresseetdesphasesd'analyse visuelledesdonnées.durantlesphasesdenavigation,l'utilisateurpeutsecontenterd'uneversion simplifiée desdonnéesquiluipermetdeserepérerdanslemodèle,parcontredanslesphase d'analyselesdonnéesaffichéesdoiventêtreprochesdesdonnéesréelles.partantdeceprincipe,le serveur intermédiaire calcule des représentations à différentes résolutions des données brutes. Lorsquel'utilisateurchangedepointdevue,lesdonnéesdelarésolutionlaplusfaibleluisont envoyées,lorsquelepointdevuesestabilise,leserveurdedonnéesaugmentelarésolutiondes donnéesqu'iltransmetàlavisualisation.enprocédantainsi,onpeutfluidifierlanavigationdansles donnéesaudétrimentdelaqualitéd'affichage,maisretrouverlesdonnéescomplèteslorsquele point de vue s'est stabilisé. Cette technique permet aussi d'adapter la résolution maximale des donnéesenfonctiondudispositifd'affichage.eneffet,sil'utilisateurveuteffectuerunaffichagesur unordinateurdebureauavecpeuderessourcesgraphiques,leserveurintermédiairepeutéviter d'envoyerlesrésolutionslesplushautesdesdonnées. DansleprojetVISUS,lerôleduserveurdedonnéesestnonseulementdecalculeretgérerlamulti résolutionmaisilpermetaussideréorganiserlesdonnéesafind'optimiserlescommunicationsentre ce serveur et la visualisation. Il s'agit de définir la structure de données qui va permettre de minimiserlesphasesd'explorationetd'extractiondesdonnéesàvisualiser.onretrouvecetteidée égalementdans[7]quis'appuiesurdu«chessboarding»pourréduirelestempsd'accèsetlataille descommunicationsouencoredans[32]quiluiutiliselestandardhdf5. Leprincipalavantagedecetteapprocheestbienévidemmentd'éviterlesécueilsdudatastreaming en permettant une navigation interactive dans les données. Cette navigation se fait avec une dégradationtemporairedelaqualitéd'affichage,cequipeutêtreunecontrainteacceptablepour l'utilisateur.ilfautquandmêmenoterquedanslessystèmeétudiés,lesdonnéesvariantaucoursdu tempsnesontpasévoquées.deplus,ilsubsisteunedifficultémajeuredanslamiseenoeuvrede cettetechnique,c'estl'existenced'unalgorithmeefficacedecalculdelamulti résolutionpourle typededonnéesquel'utilisateurveutafficher.c'estd'ailleurslecoeurduprojetvisus,quia développéplusieursalgorithmespourdifférentstypesdedonnéesmaisquin'estévidemmentpas exhaustif. Onpeutremarquerquecetteapprocheestvraimenttrèsprocheduscénario3puisquelerôledu serveur intermédiaire est de préparer les données en vue de l'affichage et on peut tout à fait imaginerquedanscecadre,ceserveurpourraiteffectuerunepartiedurendu. 3. Scénario3(Approchesmixtes) Dans le cadreduscénario1,pourobtenirdebonnesperformances,ilfautunréseaudefaible latencepourpermettrelafluiditédel'affichagetoutenoffrantuntauxd'interactionélevéavec l'utilisateur.parcontreilestdifficilementapplicableàdessupportsd'affichagecommelecaveou lemurd'images.pourlescénario2,unbonframerateestdépendantdelabandepassanteduréseau et des ressources graphiques du client. Cependant, pour de gros volumes de données il peut atteindrerapidementseslimitesetnepermettreunebonneinteractionqu'auprixd'unedégradation 13/62

14 delaqualitédel'image(mêmetemporaire). Lescénario3consisteenuncompromisentrecesdeuxdémarches.Lessolutionsrépondantàce scénariopeuventêtrediviséesendeuxcatégories.lapremièreproposeunerépartitionentrele serveuretleclientbasésuruncalculdelagéométrieparlepremieretunepriseenchargedurendu finalparledeuxième.danscecas,l'interactionavecl'utilisateurestcomplèteetleréseaun'est sollicitéquelorsquelesdonnéesàvisualiservarientdansletemps.lasecondecatégorieestplus complexeetsiellepermetunerépartitiondecharges,ellenepermetqu'uneinteractionpartielle avecl'utilisateur. Danslapartie3,nousverronsquedenombreuxsystèmesautonomesproposentunevisualisation distanteselonlescénario3.danscettepartienousavonschoisideprésentervisapultcarils'agit d'uneréférencepourlavisualisationdistante,ainsiqu'unepartiedestravauxdusciinstitutepour les différentes répartitions de charges proposées. Dans la dernière section, nous décrirons une architectureproposéeparlecentrederechercheamesdelanasa.cettedernièreestuneapproche mixteunpeudifférentedanslesensoùelleexploitetroissitesdifférentspourlegénérationdes donnéesàvisualiser,lecalculdurenduetenfinl'affichage. 3.1 Visapult Visapult[4;50;51]estunesolutioncomplètedevisualisationdistantedegrosvolumesdedonnées développéeparlevisualizationgroupdulawrenceberkeleynationallaboratory.ceprojetest affichécommeunprojetterminéaveccommesuccesseurdivadontlesprincipesserontdécritsau chapitresuivant.cependant,leprototypevisapultestencoredisponibleenopensource. Visapultproposeunerépartitiondechargesentreleserveuretleclientpourlecalculderendu. Cependant,cettesolutionappartientàlacatégorie2quenousavonsdéfiniedanslesensoùledegré d'interaction avec l'utilisateur est limité. Seul un ensemble de transformations applicables aux donnéessansdégradationdel'imagesontpossibles. Lesystèmeestcomposédedeuxparties.D'uncôtéleserveur,appeléleback end,effectueles calculsderenduvolumique.del'autreleclientquiestappelélefront endouleviewerreconstruit l'imageetl'affiche.l'originalitédecettearchitectureestl'algorithmederenduvolumiqueutilisédit IBRAVRpourImage BasedRendering AssistedVolumeRendering[28].Cetalgorithmeconsiste àgénérerunensembled'imagesdesdonnéesdepuisunpointdevueenutilisantlerenduvolumique d'uncertainnombredesousvolumesappelés«slabs»quicorrespondentàdestranchesduvolume englobant.lerendudechaquesousvolumeestcalculéettransmisauviewerquireconstruitalors l'image.cependant,puisquelerenduvolumiquedes«slabs»estcalculéparleserveuràpartird'un point de vue donné, seules des interactions de type rotation de faible amplitude peuvent être appliquéesauxdonnéessansdégradationdel'image. 14/62

15 L'architecturedeVisapultestdonnéefigure 8.Leback endestainsiparallèleetécritenmpi. Chaqueprocesseurreçoituncertainnombredesousvolumesdontilcalculelerendu.Lefront end estmulti threadéenutilisantpthreadsetutiliseopenrmscenegraph.lescommunicationssont réaliséesselonunprotocoleadhocdetypetcpdetellemanièrequechaqueimage2dgénéréepar unprocesseursoitreçueettraitéeparunthreadauniveaudufront end. La dernière version Visapult2, améliore le modèle en offrant une parallélisation à partir d'un Lesdonnées Proc1 Proc2 TCP TCP thread1 thread2 Scene Graph Rendu Procn TCP threadn Figure8:ArchitecturedeVisapult découpageenblocsduvolumeàrendreafind'assurerunemeilleurescalabilitéetd'êtreindépendant delaformeduvolume.eneffet,un«slab»peutêtreencoretropgrandenfonctiondecetteforme pour tenir dans l'espace mémoire d'un processeur. De plus le rendu est désormais effectué en fonctiondes6directionsprimairesetcesontdonc6rendusquisonttransmispourlarecomposition del'imagefinalesurleclient. 3.2 PrototypeduSCIInstitute Universitédel'Utah Ils'agitd'unMaster'sthesisquiaétépubliédansIEEEVisualizationen2002parEricJ.Lukeet CharlesD.HansenduSCIInstitute [47].Cetteéquipeestégalementàl'originedeSCIRun,un environnement de programmationpour le calcul scientifique et la visualisation et sice master constitue leur première approche de la visualisation distante, nous verrons que désormais leur recherchesurcethèmeseconcentresurl'approcheparcomposantsavecscirun2. Ce travail décrit une infrastructure complète pour de la visualisation distante offrant les trois possibilitésdelocaliserlelieudurenduenlocal,àdistanceouenrépartissantlacharge.cette infrastructurereposesurunearchitectureclientserveuravecunensembled'interfacesquipermet d'abstraire l'utilisateur des problèmes de communication par exemple. Seul un prototype a été développémaisilapermisdevalideruneapprochemixteégalementbaséesurlerendud'images. Lesinteractionsavecl'utilisateursontillimitéesdanslesensoùpourchaquechangementdepoint devue,leserveurreçoitl'information,procèdeaucalculdupré renduetletransmetauclient. Larépartition,pré rendusurleserveur,rendusurleclient,s'appuiesurl'algorithmesuivant.dans unpremiertempslecolorbufferesttransmisenimagestreamingauclient.ensuiteleserveurprend enchargelecalculdudepthbufferpourchaquenouveaupointdevue.alaréceptiondecebuffer, 15/62

16 le client termine le calcul de la texture correspondante et affiche le résultat. Les tests de ce prototypesurunserveursgiorigin2000,unclientdetypepentiumiiietunréseauethernetont montréquecetteapprochemixtegénéraitunmeilleurframeratequel'imagestreamingouquela solutionderépartirlachargeentreleserveurpourlagéométrieetleclientpourlerendufinal. 3.3 VisualisationconcurrentedeAmes(NASAAmesResearchCenter) Lestravauxdécritsicisontissusd'unepublicationrécentedeDavidEllsworthetal[61].L'objectif généralestlavisualisationconcurrentedéfiniecommelavisualisationetl'interprétationtempsréel desdonnéesaufuretàmesuredeleurgénération(time varyingdata).cestravauxapparaissent commeuneapprochemixtedanslesensoùlecouplagesimulation/visualisationesteffectuésur troissites.ilrespecteainsiàlafoislescénario2pourletransfertdesdonnéesauserveurderendu etlescénario1pourletransfertdesimagesauserveurd'affichage. LeprojetMAP'051s'intéresseàlacompréhensiondesphénomènesdecyclonestropicaux.Ilsebase sur GEOS4 (finite volume general circulation model) une simulation parallèle hybride MPI et OpenMPquigénèreàchaqueitérationdesrésultatsquidoiventêtrevisualisés(soit19.4GBde donnéesàtraiter). Ledéploiementdel'applicationestlesuivant: lasimulations'exécutesurunegrappecomposéede20noeudssgialtixetécritsurun segmentmémoirepartagésesrésultats, unprocessusindépendantlitsesdonnéesetlestransmetviaunréseauhautdébitinfiniband àunnoeudspécifiquedelagrappe, Leprocessusrecevantlesdonnéessechargedelestransmettreviaunréseauprivébasésur TCPauxdifférentsnoeudsdelagrappegraphique, leserveurderendueffectuelagénérationdesimagesetlesencodeauformatmpegavant d'écrirelerésultatvianfssurunserveurdefichiers, ceserveurdefichiersrelaiecesimagesaunoeudmaîtreduserveurd'affichagevia des requêtesssh, enfinlesnoeudsd'affichagereçoiventàleurtourlesimagesetprocèdentàl'affichage. L'originalitédecetexempleestdetraiterdesdonnéesvariantdansletempsavecpourobjectifdene paspénaliserunesimulationdéjàcomplexe,parl'extractiondesdonnéesetleurvisualisation.de plusellepermetd'illustrerunepossiblecombinaisondestechniquesrelativesauscénario2etau scénario 3 avec un enjeu plus fort sur le serveur d'affichage qui peut être n'importe où. Les performancesrestentdoncdépendantesdel'efficacitédelacompressionmpegutilisée.cependant, cetteapprocheresteadhocetfortementliéeauxmoyensmatérielsdisponiblespourleprojet,soient unegrappedecalculs,unegrappegraphique,unserveurdefichiersetenfinunegrapped'affichage /62

17 17/62

18 III. Modèlesdecommunications La visualisation distante nécessite d'étudier les solutions d'un point vue répartition du pipeline graphiqueobjetduchapitreprécédentmaiségalementd'unpointdevuemodèledecommunications associéauréseaugrandedistanceenjeudanscecontexte.lessystèmesautonomesquenousallons décriresebasenttoussurundecesmodèlesquipeutallerduplussimpleavecl'utilisationdes socketsàdesmodèlespluscomplexesquipeuventdépasserlecadredelavisualisationdistante. Cependant,cesdernierssontplusadaptésauxenjeuxdesréseauxdetypeGrid.Etonpeutpenser qu'ilsserontdeplusenplusutilisésaufuretàmesuredeleurmaturitésurtoutlorsquelessystèmes de visualisation distante souhaiteront traiter des problèmes plus complexes tenant compte par exempledelavariationdesdonnéesdansletemps. 1. RéseausurlemodèleTCP/IP La plupart des systèmes de visualisation distante étudiés dans ce rapport se basent sur des communicationsutilisantdessocketstcp/ip.bienquepeud'articlesindiquentlesraisonsdece choix,onpeutfacilementlesdeviner.toutd'abordcemodèledecommunicationestunstandard trèslargementrépanduquelquesoitlesystèmed'exploitationetletypederéseauutiliséetpar conséquentilestconnudetouslesprogrammeurs.ilestdeplusassezsimpleàmettreenoeuvreet permetdetransférerefficacementdegrosvolumededonnées.cechoixpeutdoncparaîtretrès pertinent mais en fait il comporte un certain nombre d'inconvénients qu'il est important de souligner.cesinconvénientssontliésaucaractèretrèsgénéralistedetcp/ip.afindemieuxles comprendrenousallonstoutd'abordfairequelquesrappelssurlemodèlederéseautcp/ip. IP(InternetProtocol)estunprotocoleréseauquiaétéimplémentéaudessusdelaquasitotalitédes protocoles de liaisons existants sur le marché. TCP (Transmission Control Protocol) est un protocoledetransportconnectéquiseplaceaudessusd'ip.tcpgarantitnotammentàl'expéditeur ladélivrancedesdonnéesaudestinataire.udp(userdatagramprotocol)sesitueaumêmeniveau quetcp,iloffredoncdesservicessimilairesmaisilnegarantitpasladélivrancedesdonnéesau destinataire.decettemanièreudppermetdestransmissionsplusrapidesquecelledetcp,cequi peutêtretrèsintéressantdanslecadredel'imagestreamingparexemple,oùonpeutimaginerqu'il n'estpastrèsimportantdeperdreuneimagedetempsentempsmaisoùlavitessedetransmission estextrêmementimportante. LemodèledecommunicationTCP/IPadoncunaspectassezrudimentairedanslesensoùilpermet uniquement des transferts de données non typées entre deux machines2. De ce fait on peut implémenteràpeuprèsn'importequeltypedecommunicationensebasantsurlessocketstcp/ip, maiscelasignifiequetcpneprendrapasenchargeletypedesdonnéesquel'ontransfère.par conséquentc'estàl'applicationquiutiliselaliaisonparsocketdemettreenplacetoutelagestion spécifique aux données transférées. Il en résulte que chaque système de visualisation distante utilisanttcp/ipadûimplémenterdessolutionsadhocpoureffectuercettegestion.onpeutnoter quecettegestionn'estjamaisdécritepourlessystèmesétudiés.seullesystèmecovisefaitétatde la mise en place d'un protocole optimisé d'échanges de données entre ses composants sans le décrire. 2 UDPpermetdefairedeladiffusiondedonnéesàpartird'unemachineàdestinationdeplusieursmachinesmaiscela nécessiteleplussouventunegestionassezpointuedusuividesdonnéesenvoyéesetreçues. 18/62

19 Laconséquencedetoutceciestqu'avecTCP/IPilesttrèssimpledefaireunecommunicationpoint à point entre deux entités, ce qui est le scénario le plus souvent retenu dans le cadre de la visualisationdistante.celapermetrapidementdetesterlavaliditéd'unesolution.lepassagedela communicationpointàpointàunecommunicationpluscomplexe(entrenserveursdedonnéesetm machines de visualisation par exemple) est loin d'être trivial et demande des développements spécifiquescomplexes. 2. Approcheparcomposants Lescomposantslogicielsconstituentunmodèledeprogrammationassezrécentdontl'objectifest defavoriseruneapprocheplusmodulairedudéveloppementdecodesetleurré utilisation.un composant se définitcommel'implémentation d'un algorithme quelqu'ilsoitplusunensemble d'interfacesappeléesports,quidéterminelesliensdececomposantavecl'extérieur.l'application estalorsréaliséeeninter connectantunensembledecomposantsgrâceàladéfinitiondeleurs ports.l'ensembledesrèglesquirégissentcesliensetleurimplémentationestappelél'infrastructure d'intégration des composants. Enfin, l'association de l'infrastructure et de tous les outils pour développerl'applicationparcomposantsconstituel'architectureparcomposants.plusieursmodèles decomposantslogicielsexistent.parmiceuxadaptésauxcalculsscientifiques,ontrouveccm (CorbaComponentModel)etCCA(CommonComponentArchitecture)quifontl'objetdansles deuxcasd'unevolontédenormalisationviadesconsortiums,omg(objectmanagementgroup) pourccm3etccaforumpourcca CCM LemodèleCCM [9] estlaspécificationcorbadescomposantslogicielsparomg.laversion CORBA2.0n'estpasuneapprocheparcomposantsmaisunearchitectureobjetsdistribués.La version CORBA 3.0 la complète avec de nouveaux services tels que la composition et le déploiementdesobjets/composants.cettedernièredevientuneréelleapprocheparcomposants. CemodèleCCMestrelativementcomplexe.Ils'articuleautourd'unbusd'objetsrépartisouORB (ObjectRequestBroker)quiassureletransportdesrequêtesentredesobjetsquiappartiennentà unedescatégoriessuivantes: servicesobjetscommunsquifournissentdesabstractionsauxfonctionssystèmetellesquela sécuritéoulenommageetquirendentlesapplicationsindépendantesdesimplémentations lorsquecesservicessontutilisés, interfacesdedomainesquiconcernentlesobjetsmétiersrelatifàundomained'activités, utilitaires communs qui peuvent offrir une abstraction supplémentaire pour des fonctionnalitéscommunesàungrandnombred'applications(gui,gestiondestâches,...), objetsapplicatifsquisontlesmodulesobjetsdéveloppésparl'utilisateur. Dansle casleplussimplequinousintéresse,lebuscorbaestutilisépourletransportdes requêtesentredesobjetsapplicatifsdontledéveloppementestàlachargedel'utilisateur. Unobjetestdéfinidansunlangagedeprogrammationquelconquemaispossèdeuneinterfaceécrite forum.org/ 19/62

20 enidl(interfacedefinitionlanguage)quipermetdedécriresonmodedecommunicationavecles autresobjetsconnectésaubuscorbaselonlemodèleobjetclient/serveurcommelemontrela figure9. Application Cliente BUSCORBA Code d'implantation Référence Requête Objet Objet del'objet CORBA Activation Interface del'objet Application Serveur Figure9:LemodèleobjetdeCORBA Une pré compilation des descriptions IDL des interfaces permet de les construire en tant que souchesdecommunicationquel'utilisateurpeutdésormaisutiliserpourappelerunobjetdansson applicationcliente.lorsdel'exécutiondel'application,cetteinvocationestalorspriseenchargepar lebuscorbademanièretransparentepourl'utilisateurdanslesensoùpourluitoutsepasse comme si l'objet était local. Le bus applique alors la bonne invocation en fonction du lieu d'exécutiondel'objetappeléquipeutêtresurlemêmeprocessus,surunprocessusdifférentmais surunemêmemachineousurunemachinedifférente.cependant,cettetransparencedépendde l'implémentationcorbautiliséequidoitprendreenchargelestroislieuxd'exécutiondel'objet invoqué.ilestenparticulierimportantdechoisiruneimplémentationdecorbaquirespectele protocole IIOP (Internet Inter ORB protocol) qui définit la communication pour des objets distribuésutilisantleprotocoletcp/ipd'internet. Cettetechnologieestutiliséedansdenombreusessolutionsadhoc('petites'applications)réalisées parlesutilisateurseux mêmespourrépondreàunbesoindegénéricitédeleursapplicationsoude leursdéploiementssursystèmesdistribuéstellesque[34]ou[56]ouencore[20]. Par exemple, [56] décrit un framework permettant de contrôler et d'afficher le résultat d'une applicationopeninventorselonl'architectureillustréefigure10. 20/62

21 Serveur Application Open Inventor OpenGL Client CORBA Interface CORBA Bus CORBA Interface Encodeur Socket UDP Cartegraphique Framebuffer Application Fenêtre d'affichage+ évènements Décodeur Cartegraphique pbuffer Framebuffer Figure10:ArchitectureduframeworkbaséesurOpenInventor[56] Cette approche suit un modèle de programmation orienté objet permettant au client via une interfacecorbad'accéderàdistanceàdesméthodesdisponiblessurleserveur.laréceptiond'un événement de la part du client sous forme de requête CORBA, déclenche sa traduction en événement OpenInventor. L'image est alors générée dans le pbuffer qui permet d'utiliser l'accélération matérielle de la carte graphique sans effectuer d'affichage. L'image générée est encodéepuisenvoyéeauclientparuneconnexiondetypesocketudp.l'applicationd'affichagedu clientpeutêtresoituneappletjavaappliquéeàunnavigateurwebsoitunsystèmeadhoc. Cettesolutionréponddoncauscénario1del'imagestreaming.Deplus,unschémadecompression basésurlestechniquesdefluxvidéosurinternetestproposé.l'idéeestquedanslecontexted'une tellediffusionsurplusieursclients,ilfauttenircomptedeleurhétérogénéitéentermesdepuissance decalculsetdebandepassante.lecodecs'appuiesurunepyramidederésolutionspatio temporelle quitransformelesignaloriginalendeuxsous couchesderésolutionsdifférentesquisonttoutesles deuxtransmises.decettemanièretoutclientestaumoinscapabledetraiterlacouchedeplusfaible résolution. Autreexemple,dans[20],Shumilovetalproposentunearchitecturebaséesurunetransformation de GeoToolkit (bibliothèque de transformation et représentation d'objets spatio temporels géologiques) en composant CORBA via un adaptateur appelé GTA pour GeoToolKit/CORBA Adapter.AinsitoutclientcompatibleCORBAestàmêmed'accéderàlabasededonnéesetde visualiser les données correspondantes dans un navigateur. En particulier, leur implémentation proposeunclientbasésuruneinterfaceutilisateurgraphique(gui)quieffectuelarequêteàlabase dedonnées,s'appuiesurgocadpourlecalculdelagéométrieetgrapepourlerendu.ensuite unnavigateurcompatiblevrmlenrichid'uneappletjavapermetl'affichagedecesdonnéesspatio temporelles. CORBApourlecalculhauteperformance CORBA est plus souvent associé à des applications de type client/serveur simple qu'à des applicationsscientifiquespourdesraisonsd'adaptationàunmodèlefortementparallèleoudistribué oudeperformances.cependant,ilexistedesmodèlesdeprogrammationadaptésauxapplications scientifiqueshauteperformancequisontbaséssurcorba,dontcertainesimplémentationsontdes performancestrèsprochesdecellesdempi[10]. 21/62

22 Danscesens,leprojetPARIS5del'IRISAproposedifférentesextensionsdeCORBAauxobjetsou auxcomposantsdistribués. Parexemple,danslecadredumodèleorientéobjet,ceprojetproposeplusieursdéfinitionsd'un objetparallèle.dans[40],chaqueobjetparallèleestvucommeunecollectiond'objetscorbaetle langage IDL est complété de mots clés supplémentaires pour exprimer les nouvelles communications parallèles entre objets. L'inconvénient de cette approche est de modifier l'implémentation de CORBA et de nécessiter de nouveaux compilateurs tenant compte des nouvellesdéfinitionsdulangageidl.avecpaco++ [41],lechoixconsisteàajouterunniveau d'abstractionaudessusdesimplémentationsexistantesdecorba.ainsitoutobjetparallèleest égalementunecollectiond'objetscorbaselonleprincipespmd,quipeuventutilisermpipar exemplepourdescommunicationsinternes.onassocieàcetobjetparallèledeuxcontextespartagés partouslesobjetscorbaquilecomposent.lepremier«globalcontext»permetàtoutobjet parallèled'êtreunobjetcorbaetledeuxième«operationcontext»permetd'exprimertoutesles opérationsparallèles.paco++estdisponibleenopensourceetaégalementfaitl'objetdetestssur uneapplicationd'eadsdanslecadredel'acigrid RMI CCA LemodèleCCA[6]estunmodèleparcomposantslogicielsquiviselaperformancedanslecadre ducalculscientifique.parrapportauxspécificationsccm,ilsimplifielemodèledecomposantde CORBA3.0.ParcontreCORBA2.0enfonctiondesonimplémentationpeutêtreconformeau standardcca. CemodèlesebasesuruncomposantplussimplequeCORBA3.0etnecontientquedeuxtypesde portspourinvoqueruneméthode(«usesport»)oufourniruneméthode(«providesport»).il s'appuiesurunlangageidlappelésidl(scientificinterfacesdescriptionlanguage)adaptéàla description des données manipulées par les applications scientifiques comme les tableaux de dimension n parexempleetsupportantl'héritageàlajava.uneimplémentationparcomposants conforme au modèle CCA fournit donc ce langage SIDL, les différentes API et les services nécessairesàlaconstructionetlagestiondel'applicationccacommelemontrelafigure11. La particularité de l'approche CCA est d'adapter un modèle par composants aux besoins des applications scientifiques et en particulier au couplage de codes en vu des contraintes de performances de ces applications. Cette particularité s'exprime au niveau du SIDL adapté aux structures de donnéesscientifiquesmaiségalement surladéfinitiondes portsquipeuvent être directsoucollectifs.danslepremiercas,un«uses»portn'admetuneconnexionqu'àununique «provides»port.dansledeuxièmecasc'estunensemblede n «uses»portsquipeuventêtre connectésàm«provides»portsavecdanscecaslapossibilitédereprésentertouslesschémasde communicationsn mclassiques(gather,scatter,...)auxapplicationsparallèles RMI/www/fr/ 22/62

23 Figure11:L'architectured'uneapplicationCCA LesdéveloppementsCCAdisponiblesactuellementsontencorepeunombreuxetsouventdel'ordre duprototype.deplus,cetteapprocheestbienplusgénéralequelavisualisationdistantequiestle thème de ce rapport. Nous en verrons cependant un exemple dans le chapitre «Systèmes autonomes»avecscirun2.cemodèleentantquetelestmentionnédanscetétatdel'art,carilest prometteurpourtoutprojetscientifiquedontl'ambitionestdedéployerdesapplicationscomplexes detypecouplagedecodesintégrantdesoutilsdevisualisation,cesderniersétantdescomposants commelesautres.ildevraitpermettred'assurerdesmisesenoeuvred'applicationsquiprennenten comptelesbesoinsenperformanceseteninter opérabilitétoutenabstrayantlescientifiqued'une large partie des problèmes de développement relatifs à l'hétérogénéité des plate formes et aux modèlesd'échangesentrelescomposants. 3. Servicesweb De manière générale, un service web est défini comme un mode d'échanges de données via «internet»entredifférentslogicielstournantsurdesmachineshétérogènes.ils'agitdoncd'une implémentationdansunlangagequelconquequidélivreunservicequidoitpouvoirêtredécouvert etinvoquédynamiquement.unensembledenormesetdeprotocolesauseindu«webservices ProtocolStack»sontdisponibles(ouencoursdespécification)pourassurerleséchangesetl'inter opérabilité.parmicesnormes,onretrouveparexemplexmlpourleformatdedonnées,vrml pourlesdonnéesgraphiques[59],soap(simpleobjectaccessprotocol)[48]quiimplémenteun protocole RPC (Remote Procedure Call) basé sur XML pour les données et http pour les communications. Dans le cadre de la visualisation, nous pouvons définir les services web comme une mise à dispositiondedonnéesviainternetpourunaffichagedansunsimplenavigateurcompatible.les 23/62

24 solutionsquipeuventserevendiquerdetypeservicewebpourdelavisualisationdistantesemblent appartenir à deux familles distinctes. La première utilise CORBA avec une implémentation respectantlaiiopetdoncuneapprocheparobjets/composantspourassurerl'inter opérabilitéentre le serveur distantet leclient.nous retrouvons icilestravauxduprojetvisdel'universitéde Stuttgart.Ladeuxièmes'appuiesurlesoutilsdu«WebServicesProtocolStack»detypeSOAP.Le systèmegvizquiseradécritdanslapartiesuivantepeutêtreassociéàcettefamille. Cetteapprocheexisteégalementpouraccéderàdesbasesdedonnéesvolumineusesetpermettre l'affichagedecesdonnéessurdesclientslocaux.parexemplepourledomainedel'astronomie,au seinducsiro(australiannationalscientificresearchorganisation),l'atnf(australiatelescope NationalFacility)proposeunoutildevisualisationdistantedetypeservicewebRVS7 (Remote Visualisation System).Cettesolutionlogicielleestbaséesurunserveuraccédantauxbasesde données des images FITS eteffectuant lescalculset sur unclientdetype viewer java qui se connecteauserveurrvsenluiindiquantlabasededonnéesdetravailetprocèdeàl'affichagedes imagesreçues.onretrouvecetteapprocheaussidansaladindéveloppéparlecentrededonnées astronomiques de Strasbourg dont une démonstration est disponible à l'adresse strasbg.fr/java/nph aladin.pl.làencoreunviewerpluginjavad'unnavigateurwebpermetd'accéder auserveurd'imagesdigitaliséesduciel.depluscetteversionpermetégalementunaffichagedeses propresdonnéesparsuperposition. 4. Globus8 Globusnepeutêtredéfinisurlemêmeplanquelesautresprojetsderecherche.C'estplusquecela puisquesesconcepteurslepensententantqu'écosystèmedecomposantsetoutilsquiinter opèrent ensemble.leprojetestconstitué:d'unecommunautéd'utilisateursetdedéveloppeursopensource centrés sur les thèmes du calcul distribué ; d'organisations virtuelles ; et d'une fédération de ressources. La partie software est constituée du Globus Toolkit qui comporte un ensemble de bibliothèquesetdeprogrammesquirépondentauxproblèmesrencontréslorsquel'onconçoitdes systèmesdistribués.globusestaussil'infrastructurequisupportelacommunauté:répertoiresde codes,systèmededébogage,listes,etc...decetensembledoitémergerdessolutions,dessavoir faire classiques sur lesquels s'appuyer pour faciliter la conception des futures applications sur Grille. LapartieconcrèteetvisiblepourlesutilisateursresteprincipalementleGlobusToolkit.Ilfournit unevariétédeservicesallantd'implémentationsdeservicestelsquelagestiondesressources,la transmission des données et la découverte de services jusqu'aux outils pour en construire de nouveaux:webservices(java,c,python).globusfournituneinfrastructuredesécuritépour l'authentification,l'identification,l'autorisationd'accès.enfinilfournitauxclientsàlafoisdesapi (dans différents langages) ainsi que des programmes en ligne de commande pour accéder aux servicesglobus. LadernièreversionduGolbusToolkitestlanuméroquatre(GT4).Cettedernièrefaitunusage extensif des services web afin de définir ses interfaces et structurer ses composants. Leurs protocolessontadaptéspourlesinteractionsfaiblementcoupléesquecertainsargumententcomme préférables pour concevoir des systèmes distribués robustes. Leur but est de concevoir des architecturesorientéesservices,structuréesenservicescommunicantsdécritsdemanièreuniforme /62

25 Apartirduconstatquemêmelesapplicationstrèsspécifiquesàundomainepartagententreellesla nécessité de manipuler une infrastructure, GT4 fournit des services d'infrastructure qui implémententlagestionducalcul,dustockageetdesautresressources. ArchitectureGT4 Lafigure 12 illustrelesdifférentsaspectsduglobustoolkit4constituédetroisensemblesde composants: Services(enbasàgauche):gestiondel'exécution(GRAM),accèsauxdonnées(GridFTP, RFT,OGSA DAI),gestiondelaréplication(RLS,DRS),monitorageetdécouverte(Index, Trigger,WebMDS),gestiondelasécurité(MyProxy,Delegation,SimpleCA),gestiondes instruments(gtcp);laplupartsontdesserviceswebmaiscertains(enbasàdroite)sont implémentésdansd'autreslangageset/ouprotocoles. Troiscontainerssontréservéspourhébergerlesservicesdesutilisateurs.Ilsfournissentles mécanismes(compatiblewebservices)fréquentslorsquel'onconçoitdesservices. DesbibliothèquesclientesenC,JAVAetPythonpourinvoquerdesopérationsGT4ou cellesdéveloppéesparlesutilisateurs. Figure12:LescomposantsGT4etleursinteractions(lesboîtesblanchessontlescodesutilisateurs) Deparsagénéricité,sonarchitectureetsesservices,Globussembleseprêteràuneutilisationpour visualiserdesdonnéesmassivesàdistance.pourtantpeudesolutionssontcitées.parmicelles ci uneexpérimentationretientl'attention[21]puisqu'ellemetenoeuvreuneconnexionentrelesetats UnisetlaHollandeauxfinsdecoupleruncomposantdecollaborationavecuncomposantderendu hauterésolutionàdistance.lecomposantdecollaborationrendetdiffusedesimagesenfaible résolution, calculées sur un sous échantillonnage des données. Il utilise VTK (extraction d'isosurfacessurdesdonnéessouséchantillonnées)etchromium [8]pourparalléliserlerenduet 25/62

26 décomposerlesimagesensort lastafind'expédierdesfluxvidéosséparésetcompressésenh261. Lecomposantdecollaborationesttypiquementcapablederendreuneimage3x2pouratteindre 1056x576. Le composant de rendu haute résolution est un prototype de parallélisation de visualisationutilisantl'ensemblecompletdesdonnées.lespiècesdel'imagesontensuiteenvoyées enstreamingpuiscomposéespourformerl'imagefinale.celafournitauxutilisateursfinauxdes images(2048x1536)quis'affinentprogressivement.lescalculsdesimagesetleurstransfertssont réalisésviampich G2uneimplémentationdeMPI 1quiutiliseGlobuspouradapterMPIàla Grille.MPICH G2estàmêmed'utiliserdessocketsparallèlesviaGridFTP.Cetexempleillustre bien que si Globus n'est pas explicitement un environnement de visualisation, il en facilite notablement la conception si celui ci doit prendre en charge la visualisation distante, la parallélisationdurendu,lasécuritéetc. 5. ApprocheFlowVR Ledéveloppementd'applicationsdevisualisationscientifiquedistribuéesavecstreamingetgestion de la latence rencontre des difficultés similaires à celles que l'on doit surmonter lors du développementdesapplicationsderéalitévirtuelle(rv)ambitieusesquiincluentdenombreuses simulationsetdesinteractionscomplexes.ondoitdanslesdeuxcadres,fairefaceàdeuxdifficultés majeures: gestion ardue du génie logiciel où de multiples morceaux de codes, développés par différentsacteurs,àdifférentespériodes,doiventêtreassemblésdansuncadreuniqueet fonctionnerensemble; surmonterleslimitesdumatérielenmultipliantlesunitésdetraitement(gpu,cpu,...) mais avec le désavantage majeur d'ajouter des difficultés supplémentaires liées à la parallélisationdetâches,pipelineoudedonnées. Ilexistedenombreuxoutilsquifacilitentl'utilisationdesmachinesparallèlesactuelles(engénéral desarchitecturesfaiblementcoupléesdetypecluster)pourlarv.parexemplechromium[8]porte lamachinerieopenglsurunclusterdevisualisation.d'autresoutilsproposentdesdiffusionsafin desynchroniserdemultiplescopiesd'applicationsplusoumoinsparallèles [37].Commedansle casdelavisualisationdistribuée,lesoutilssontmultiplesettoussontutilesàdiverstitres.ilest simplementdifficiledechoisirparmieuxetdelescombiner.onnoteraqueleparcoursdataflow strictementfifodesapplicationsclassiquesdevisualisationscientifiqueestpluscontraintetrend difficilelagestiondelavisualisationdistribuéesansralentissementliéàdesfortessynchronisations et un trafic réseau lourd. Les applications classiques de RV relâchent ces contraintes non en proposantunegestionfinedesynchronisationmaisenproposantd'extrapolerlescomportements calculésàdistancepourabsorberlalatenceduréseau(estimationdeposition). 5.1 Descriptiongénérale FlowVR propose un cadre pour le développement d'applications ambitieuses de RV [17]. Les applications sont fortement modulaires pour faciliter le développement et pour être aisément déployéessurlesarchitecturesdesclustersdepc.flowvrétendlecadredataflowtraditionnelen autorisantdescommunicationsetdessynchronisationsbienpluscomplexesquecellesdesapi classiquesparallèles.pourautant,lasémantiquedesapplicationsn'estpasforcémentlaisséesousla responsabilitédesdéveloppeursmaisellepeutêtregéréeviadesélémentspré intégrésàflowvr. Ainsi,ilestpossibled'utiliserFlowVRpourréaliserdescodesnonspécifiquementRV.Toutcode parallèlesurcluster(etparextension,probablementsurlagrille)peuttireravantagedeflowvr, 26/62

27 soitpour ses capacitésdegénielogicieletlavisionglobalequ'ilapporteducluster,soit,plus finement, lorsque la gestion des interactions, des framerates interactifs ou du pilotage des applicationsdevientcomplexe. 5.2 ArchitectureFlowVR Une application FlowVR est composée de modules qui échangent des données via un réseau FlowVR(voirfigure13). Un module est typiquement uncode existant (éventuellement lui même parallèle) modifié à la margeparl'ajoutd'appelsàdesfonctionsflowvr.unmodules'exécutedanssonprocessus,ilya doncpeud'effortàfournirpourtransférerd'ancienscodesversflowvr.lesmodulesn'ontpasà tenircomptedirectementducalculdesautresmodules. Figure 13 :Exempled'unréseauFlowVRcomposédeliensentredesmodules séquentielsouparallèles Cesderniersn'échangentleursdonnéesetnesesynchronisentqueviades DémonsFlowVR qui 27/62

28 s'exécutentsurchacunedesmachinesducluster.cesontlesdémonsquigèrentlestransfertsde donnéesentrelesmachinessinécessaire.cetteapprochepermetdesdéploiementsdifférentset mêmedesagencementsmultiplesdesmodulesdel'applicationflowvrsansnouvellecompilation. Lesconnexionsentrelesmodulespeuventêtresimples(fifodetypeMPIparexemple)oubienplus complexes:filtragesurlesdonnées,prélèvement,estimationdeposition,découpeselonlecônede vision,communicationscollectives,etc.cecontrôlefinpermetdetireravantagedelaspécificitéde l'application, des'adapteràl'architecture matérielle toutentenantcomptedes besoinsréels de l'utilisateur en termes de latence et de taux de rafraîchissement. Cette expressivité doit probablementpouvoiroffrirlesmêmesavantagesdanslecadredelavisualisationdistribuéeet distante. Une chaîne de visualisation distante doit pouvoir être transposée en graphe FlowVR (presquelittéralementdansunpremiertemps)puisutiliserlesmécanismesflowvretadapterles transfertsdedonnéesàlabandepassanteduréseau,ouàd'autrescritèrestelsquelapertinencedes résultats d'un calcul ou bien la forte/faible demande en interactivité à un instant donné. Par exemple,unfiltragemettantenoeuvreunmécanismedelodenfonctiond'informationsexternes qui proviennent de modules pourrait simplifier à la demande, les informations en sortie de simulations.etdanslecadredeflowvrcemécanismepourraitêtredéveloppéindépendamment descodesdesimulationsetmisenoeuvreenfonctiondutypededéploiement. Figure14:Processusdecréationd'uneapplicationFlowVR FlowVRestunesuitecomplèted'outilspourdévelopperlesmodules,lesréseauxd'interconnexion, pourplaquerl'applicationcomplètesuruncluster,lalanceretpourcontrôlersonexécution.deplus ilexisteégalementdesoutilspourtraceretanalyserl'exécution.làencorecesoutilsdevraientaider fortementledéploiementd'applicationsdevisualisationsdistantes.lafigure14illustreleprocessus de développement FlowVR depuis le code des modules jusqu'aux commandes générées à destinationdudémonflowvr.notonsquelepassageàuncodeflowvrsurlagrillenécessiterait 28/62

29 une adaptationdans lamesureoùflowvr n'offrepas lesfonctionnalités propresàcesupport commelasécurité,latoléranceauxpannes,ladécouvertedeserviceetl'équilibragedecharge. UneextensiondeFlowVRpermettraitd'exprimeretdedéployerrapidementdespipelinesdistribués detraitementdesdonnéespluscomplexesethétérogènesqueceuxclassiquementproposésdansles environnements modulaires de visualisation. Par ailleurs l'aspect «composants» de FlowVR devraitpermettred'intégrer,enfonctiondesbesoins,lesniveauxdedétailsdynamiquespertinents, qui sont au coeur des approches qui se préoccupent de la visualisation des gros volumes de données.enfinlaconceptiontypiquementflowvrdecodesousformedemodulesréactifsvis à vis d'événements externes ouvre la voie vers le pilotage et le travail collaboratif et pourrait constitueruneapprocheparcomposantspertinentepourlavisualisationdistanteetsesperspectives. 29/62

30 IV. Systèmesautonomes Ilexistenombredesystèmesdevisualisationdistribuée.Laplupartsontbasésàl'originesurun systèmedevisualisationmodulairelui mêmefondésurlanotiondemodèledeflotdedonnées[31]. Danscesapplications,leprocessusentierdevisualisationestscindéenparties,ouencoremodules, qui sont inter connectées via un réseau. Les données suivent le réseau et sont modifiées progressivementjusqu'àêtretransforméesenimagesvisionnéesparlescientifique(figure15). Simulation Sélection des données Données vers géométrie Rendu de la géométrie Données Figure15:Pipelinegraphiquedessystèmesdevisualisationmodulaires Sicescénarioaétécrééinitialementpourvisualiserdesdonnéesenregistrées,ilestaussiadapté auxdonnéesgénéréesàlavoléepardessimulations(voirfigure15).laplupartdesapplicationsde visualisationsontconçuessurcemodèle.chronologiquement,undespremiersexemplesestavs (version1) [2].Typiquement,ilfournitunéditeurvisuelafindeconstruirelesapplications en connectant entre eux des blocs de traitement. Il est probable que l'expressivité et la facilité d'utilisationdecettemétaphoredeconceptionsoientàl'originedusuccèsdesenvironnementsde visualisation modulaires. De par les notions de réseau et de modules de traitement, il devient naturel de passer de systèmes mono machine à des applications distribuées (AVS, VTK, IRIS Explorer, OpenDX...) [3; 33; 60]. Ce sont principalement ces applications, au fonctionnement relativementautonomes,quisontdécritesdanscettepartie. 1. Amira AmiraestunsystèmeorientéobjetdevisualisationbasésurOpenInventor[1;62].Aladifférence desautressystèmesdevisualisationdiscutésici,iln'estpasbasésurlemodèleàflotdedonnées. AulieudecelalesobjetssontpersistantsetaccessiblesvialesinterfacesC++desclassesdonnées. Pourcetteraison,ilestmaladaptéàladistributiondutravailenmodepipeline.Parcontreilest extensibleparl'utilisateuretlemodedeconceptionestbasésurunemétaphoreprochedecelle adoptéeparlesenvironnementsmodulairesdevisualisationsoitdesmodulesconnectésentreeux. Toutefois, on peut adapter Amira à la visualisation distante en écrivant des modules de communicationavecunesimulation(pourquoipasenutilisantunelibrairedecommunicationetde synchronisationtellequeflowvr [17])oumêmeendialoguantavecuneautreinstanced'Amira (méthode adoptée dans la version Amira VR à rendu parallèle reprenant ainsi une partie des 30/62

31 fonctionnalitésetdessolutionsdulogicieldervparallèlenetjuggler[37]). 2. Covise Covise[12]estunenvironnementdetravailcollaboratifdéveloppéàl'originepardeschercheursdu laboratoirehlrsdel'universitédestuttgart.lesdernièresversionsdecelogicielsontdevenues commerciales, elles sont développées par la société VISENSO après l'arrêt des activités de Vircinity. 2.1 Approche L'idéedeCOVISEestdeproposerunenvironnementdetravailcollaboratifdistribuéquipermetteà des chercheurs et des ingénieurs de travailler à distance sur des modélisations éventuellement complexes. COVISE est conçu pour permettre à l'ensemble des participants de visualiser et d'interagirsurlesmodèlesentempsréel. 2.2 Architecture COVISEsebasesurunereprésentationcentraliséeetpropriétairedumodèled'unepartetsurun protocoleoptimisédemiseàjourdecettereprésentationparlesdifférentsacteursd'autrepart.le schémadelafigure16ci dessousdonneuneidéedel'architecturedecovise. Chaquemachineparticipantàlasessiondetravailcollaboratifpossèdeunespacemémoireréservéà COVISEainsiqu'unprocessusparticulierappelé"courtier"(Broker)chargédesmisesàjoursdes modèlesmanipulés.unemachineparticulièrejouelerôledeserveur(lamachine1danslafigure 16). Elle maintient à jour le modèle manipulé (l'objet rouge de la figure). Chaque machine participanteconserveunecopiedumodèle.lecourtierduserveurvadiffuserlesinformationsde mise à jour à l'ensemble des courtiers des autres machines qui seront chargés d'effectuer les changementsnécessaires.chaquemachinepeutensuitemanipulersapropreversiondumodèleen extrayant par exemple une iso surface. Ce travail sera effectué en local mais n'aura pas de répercussionssurlesautresparticipants. Danscettearchitecture,ilestclairqueleserveurstockelesdonnéesissuesdelasimulationet effectuelamiseenformedecesdonnéesdanslemodèledecovise.chaqueclientdoitluiaussi stockerlemodèlecoviseetildoitaussiavoirlesressourcesnécessairespourmettreàjource modèle.c'estaussileclientquiestchargéducalculderendu(scénario2).cetyped'architecture permet donc des'affranchir des contraintes delatence duréseaupourtoutes lesmanipulations localesdumodèlemaisnécessitedesressourcesenmémoireetencalculsurlesclients.leserveur doitaussiêtrecapable,enplusdelagestiondumodèle,detransmettreefficacementlesmisesàjour àtouscesclients. 31/62

32 COVER Manipulation (extr. surface) Courtier Machine 2 Courtier Machine 1 Simulation Figure16:ArchitecturedeCOVISE 3. EnSight EnSight[14]estunlogicielcommercialdevisualisationscientifiquedéveloppéauxEtats Unispar lasociétécei.ensightesttrèslargementutilisépardegrandsorganismesderechercheaméricains commelanasaoulelaboratoiredelosalamos(lanl)etdesorganismesfrançaistelsqueedf, SNECMA/SAFRANouleCEA/DAM. 3.1 Approche CelogicielsedéclineenplusieursversionsallantdeEnSightpersonalmonoposte,àEnSightDR quiproposedesfonctionnalitéspourletraitementdedonnéesetlerendudistribué.ilsemblequela partiedistribuéed'ensightaétélargementdéveloppéeauseind'unecollaborationentreceietlos Alamos. 3.2 Architecture L'architectured'EnSightpeutallerdusimplemodeclient/serveuràunearchitecturecomplètement distribuéeoùlasourcededonnéesetlerendusontdistribuéscommeillustréfigure 17.EnSight permetnotammentdedistribueruniquementlapartieclienteoulapartieserveurenfonctiondes besoinsdel'applicationetdesressourcesmatériellesdisponibles.danscettearchitecture,lapartie serveurvajusqu'aucalculdelagéométriequiseraenvoyéeàlapartieclientquielles'occuperadu renduetdel'affichage. 32/62

33 Client Client ClientMaitre Client Client CollaborationHUB Serveurdeserveurs Serveur Serveur Serveur Serveur Serveur Figure17:Différentesarchitecturesd'EnSightDR L'architecturedistribuéedelapartieserveurs'appuiesurunserveurdeserveurs(abrégéenSOS) dontlerôleprincipalestdecoordonnerletravaildechacundesserveurs.ilpeutparexemple prendreenchargelarépartitiondesdonnéesentrechacundesserveurs.c'estaussilesosquiprend enchargelarecompositiondelagéométriecalculéeparchacundesserveursetlarépartitionvers lesdifférentsclientsenessayantd'équilibrerlescharges. Danslapartiecliente,plusieursscénariossontenvisagésenfonctiondumatérieletdesbesoins d'affichage. Le clients'exécutesurunemachineparallèleàmémoirepartagée.danscecasensight utiliseplusieursthreadspouraccéderauxdifférentescartesgraphiquesdelamachinequi faitlerendu. Leclients'exécutesurunemachineparallèleàmémoiredistribuée(typeclusterdePC). Danscecaslapartiecliented'EnSightestdistribuée.Touslesclients,àpartleclient maître, sontpassifsdupointdevuedel'interaction.leclient maîtreparcontreapourrôleprincipal deprendreenchargelesinteractionsdel'utilisateur.cesinteractionssontdiffuséesviale HUB de collaboration vers les différents clients. Le HUB de collaboration et le SOS échangentdesinformationsafindecontrôleretd'effectuerlarépartitiondelagéométrie entrelesdifférentsclients.ladistributiondesdonnéespeutallerdelasimpleréplicationdes primitives graphiques à une réelle distribution avec équilibrage de charge. Le mode réplicationnepermetpasd'afficherplusdedonnéesquecequ'onpourraitfairesurunseul client,maisilpermetdegérersimplementetefficacementl'affichagemulti écran.onpeut aussiconfieràchromiumlagestiondurenduparallèlepourlerendumulti ecran. Danslecasd'unaffichagesurunseulécranlarecompositiondel'imageproduiteparles clientsensightpeuventsefairesoitparl'intermédiairedu«ceiparallelcompositor»,soit 33/62

34 enutilisantchromium. Touteslescommunicationsentrelesdifférentsacteursdel'applicationEnSightsefontviaTCP/IP. Peud'informationssontdonnéessurleprotocoleutilisé,maisilsemblequelaconnexionentrele SOSetleHUBdecollaborationestlepointsensibledecettearchitecturecartoutelagéométrie passeparcelien.robertj.karesdulaboratoiredelosalamos[15]donnecependantuncertain nombred'indicationssurlespossibilitésoffertesparcettearchitecturedanslecadredetrèsgros volumesdedonnées.parcontre,aucuneinformationentermesdeframerateoudelatencede l'interaction n'est donnée.parmilesexemplescitésparkares,ontrouve lavisualisationà Los Alamos,durésultatd'unesimulationayantgénérée21TBdedonnéesauLANLàLivermoreàplus de1600kmdedistance.lapartieserveurcontenait50serveursetlapartieclienteétait"réduite"à unesgiorigine2000.lesdeuxsitesétantreliésparunréseauspécifiquedeplusieursgigabits. CettearchitectureestmaintenantutiliséeenproductionauseindulaboratoiredeLosAlamospour visualiserlesdonnéesgénéréespardiverscodesdecalcul.l'objectifactuelestderemplacerla machine SGI par une grappe de PC sous linux en utilisant les fonctionnalités client réparti d'ensight. 4. ParaView ParaViewestuneplate formedevisualisationdistribuéedestinéeàlamanipulationefficacede grandsvolumesdedonnéesquireposesurvtkpourlesalgorithmesdetraitementetderendu. ElleestdéveloppéeparKitwaresurconceptioninitaledeJimAhrensduLANL.LelaboratoireSNL aensuitebeaucoupcontribuéàparaview. 4.1 Descriptiongénérale ParaView [42] comme illustré par la figure 18, est construit au dessus de VTK, lui même implémentéenc++etfournissantuneplate formedevisualisationparallèleet/oudistribuée.afin defournirunesolutiongénériqueauxapplicationsdevisualisation,paraviewproposedifférents modesd'exécutionducalculdurenduetdel'affichage.lemodeleplussimple«stand alone» consisteenuneexécutiondeparaviewenlocalsurunemachineparallèleouuncluster.del'autre côtéparaviewproposeunmodebasésuruneséparationduserveurenunserveurdedonnéesetun serveur de rendu plus un client qui procède à l'affichage. Dans ce cas, l'approche adoptée est l'approcheclient/serveuravecunetransmissionentreleserveurderenduetleclientsoitdela géométrieenaccordavecnotrescénario3soitdesimagesrésultantesenaccordavecnotrescénario 1. ParaView VTK Tcl OpenGL C++ Figure18:OrganisationdeParaView 34/62

35 Dans le cadred'unetransmissiondelagéométrie,paraviewfournitunalgorithmeoptimiséde redistribution des données des M noeuds du serveur de rendu aux N noeuds du client qui compléterontlerenduavantdeprocéderàl'affichage. 4.2 Infrastructure Pourexprimercesdifférentsmodesdevisualisation,ParaViews'organiseautour d'unmoduleappelécsspourclient/serveurstreamingquigèrel'invocationdesméthodes fourniesparleserveurqu'ilsoitlocalousurunsitedistant, d'un gestionnaire de serveur au dessus des modules CSS qui prend en charge l'interconnexiondesserveursauclientetquigèrelacréationdesobjetsvtk,lesrequêtes surlesdifférentsobjets,etc. d'unehiérarchiedemodulesimplémentantlesdifférentsmodesderendu. Cette hiérarchie demodulesillustrée par lafigure 19 a pourracinele moduleabstraitrender Module(RM)quijouelerôled'interfaceavecl'ensembledesobjetsderenduVTK.Lemodule Simple RM (SRM) en hérite et englobe les fonctionnalités élémentaires de rendu telles que collectiondevisuels,lumière,caméra,interaction.leseulmodulefilsdesrmestlodrmqui ajoutedesfonctionnalitésdegestiondeniveauxdedétailpouraccélérerl'affichagependantles phasesd'interaction. RenderModule SimpleRenderModule LODRenderModule CompositeRenderModule IceTDesktop CAVERenderModule RenderModule Figure19:LahiérarchiedemodulesdeParaView Ensuite le module Composite RM ajoute des outils de rendu parallèle dans le contexte client/serveur,notammentlescommunicationsinter processusetlelodparallèle.c'estcemodule quiimplémentel'algorithmeoptimisédetransfertdegéométrieentreleserveurdedonnéesetcelui derenduainsiqu'unalgorithmesort lastpourl'affichagemulti écrans.lemodulecompositeétant abstrait,lesimplémentationssontfourniesparlessous modules:icetdesktopeticetrmd'une partetcavedel'autre.lespremiersutilisentlabibliothèqueicet[29;30]pourimplémenterle module Composite et proposent une facilité de compression à travers l'algorithme SQUIRT (Sequential Unified Image Run Transfert). Le second fournit une implémentation CAVE du 35/62

36 Composite. Ainsi l'architecture fortement distribuée de ParaView et l'abstraction du rendu à travers les différentsmodesdesonexécutionfontquecetenvironnementestaprioriparfaitementadaptéàla visualisationdistanteengénéral,etenparticulierpourl'affichagemulti écransdistant. 5. VisIt VisIt [55] estunoutild'analyseetdevisualisationdegrosvolumesdedonnéesdéveloppéparle LawrenceLivermoreNationalLaboratory;VisItestdisponibleenopensource.C'estunsystème autonomemaisquipermetl'utilisation,sousformedeplug ins,d'outilspersonnelsàl'utilisateur. 5.1 Approche CetoutilsebasesuruneapprocheDataFlowsimilaireàcelled'AVSouVTK.Pluslargement prévupourdelavisualisationclassiquededonnées,ilpermetlavisualisationdistanteenintégrant lesfonctionnalitésnécessairespourl'exécutionduvieweretdel'interfacegraphiqueintégrésàvisit surunposteclientdistant. 5.2 Architecture VisItestunenvironnementcompletdedéveloppementd'applicationsd'analyseetdevisualisation dedonnéesscientifiques.c'estàlafoisunensembledebibliothèquesgraphiquesbaséessurvtk et un environnement de programmation sur le modèle Data Flow. L'architecture générale est illustréeparlafigure20.ainsiàpartirdel'interfacegraphique(gui)surleclient,ilestpossiblede seconnecteràdistancesurleserveurvisitetdeluiindiquerlesdonnéessurlesquellesonsouhaite travailler.l'applicationestalorslancéesurlesitedistantcomprenantàlafoislabasededonnées voulue et les machines de calculs ou graphiques. Les opérations sont exécutées au sein du «compute engine» qui peut être parallèle et les résultats sont envoyés au viewer local pour l'affichage.ilestégalementpossibledevisualiserdesdonnéesgénéréesentempsréelpar une simulationeninstrumentantlecodedecettedernière.le«computeengine»aalorslacharge d'accéderauxrésultatsdelasimulationsansécritureintermédiairedefichiersdestockage.toutes lescommunicationssontbaséessurdessocketsetsurrpcpourl'invocationdistantedesméthodes 36/62

37 GUI Viewer client Server sitedistant Databaseserver Data ParallelCompute Engine Figure20:ArchitecturegénéraledeVisIt Un important effort a été fait sur l'optimisation des algorithmes de pré rendu et de rendu. Essentiellement,elless'appuientsurdestechniquesderendudescènes.Ellesrespectentdoncsoitle scénario2lorsquelescommandesopenglsontdirectementtransmisesàlacartegraphiquedu clientsoitlescénario3lorsquesurlesitedistant,viamesaparexemple,lerenduesteffectuéen parallèleetquelerésultatrecomposéestenvoyéauclientaprèsoptimisationdesobjetsquifont partisounondelascène. VisItestdonctrèscompletetconstitueunenvironnementdedéveloppementautonomepourtoute application de visualisation de données scientifiques. Pour la lecture des données, VisIt est compatibleavecdenombreuxformatsdontlesprincipauxsontleformatvtketleformatsilo (développéparlellnlpourlesgrilles2dou3detlestockagedistribué)maiségalementgis, FITSouencoreleformatpropriétaired'EnsightGold.IlsupporteégalementPythoncommelangage descriptpermettantauxutilisateursdegénérerdesscénarioscomplexesdevisualisationdeleurs données(animations,...).enfin,puisquetouteslesfonctionnalitéssontimplémentéessousformede plug ins,ilestpossibled'enrichirvisitdesespropresdéveloppements.parconséquent,visitest principalementutilisécommelogicielintégréàinterfaceapplicativeprédéfinieetlangagedescript. 6. Covisa/CovisaG/gViz 6.1 Covisa/CovisaG Lemodèleàflotdedonnéesaétéconçuinitialementpourunseulutilisateur,maissonprincipe 37/62

38 permet,avecquelquesextensions,del'adapteràplusieursutilisateursquiinter connectentleurs pipelinesgraphiquesdefaçonàcequelesdonnéespuissentvoyagerd'unutilisateuràl'autre.une étape supplémentaire est franchie si on donne les moyens aux scientifiques de piloter les simulationsenmodifiantsleursparamètres,làencoreàlavolée(voirfigure21). Pilotage Simulation Sélection des données Données vers géométrie Rendu de la géométrie Données Figure21:lepipelineduflotdedonnéespilotéàchaqueétape Danscesens,COVISA[11;33]estuneextensiond'IRIXExplorerquioffre,enoutre,lapossibilité derendrecollaborativelavisualisationetlepilotage.deplus,l'émergenceducalculsurlagrille conduit à adapter les solutions de visualisation distribuée. D'où une première extension avec CovisaGdontlebutestd'utiliserGlobuspourlescommunicationsdeCOVISA.Cedernierprojet s'est,semble t il,vitemétamorphoséengviz. 6.2 ProjetgViz:Intergicieldevisualisationpourlese Sciences Le projet gviz [19; 25] a été créé par le UK e Science Core Programme, et a deux objectifs principaux. En premier lieu, le projet vise à adapter à la grille deux systèmes existants de visualisation,irisexploreretpv3,desortequelesoutilsdevisualisationsoientdisponiblesdès quepossiblepourdesutilisateursdesgrillesinformatiques[26;43].ensecondlieu,gvizdéveloppe laréflexionàpluslongtermesurlavisualisationdistribuéeetcollaborative,avecl'emploiduxml pourdécriredesdonnéesàvisualiserainsiquelesprogrammesdevisualisationeux même.autour d'irisexplorerundémonstrateuraétéconçudefaçonàdistribueràtraverslagrilleunréseaude modulescommandéviaunordinateurdebureau.ceciestréaliséd'unefaçonsécuriséeenutilisant lelogicielglobuspourremplacerlepeusûrmécanismedersh.lescapacitésdecollaboration offertesparcovisasontimmédiatementdisponibles,etainsinousobtenonsuncadrepourla visualisationcollaborativedistribuéesurgrille.uneapplicationimportantedececiestlepilotage lorsquelemodèledesimulationfonctionnesurunserveurdistant,maisestcommandéàpartird'un ordinateurdebureau.laversiongrilledepv3estcrééeenremplaçantsescommunicationsbasées 38/62

39 surpvmparunmécanismedeservicewebquiutiliselepaquetdegsoap[24].lecalculdistribué fournidesdonnéesviadesoffresdeservicewebpourlavisualisationetlesserveurspv3serelient àcelui cientantqueclientsdeserviceweb.notonsquegsoapfournituneimplantationc/c++ efficacedeserviceweb,faisantusagedessletdegsi(gridsecurityinfrastructure)auxfinsde sécurité. 6.3 Modèleencouches LemodèlegVizestconçuautourdetroiscouches: unecoucheconceptuelle; unecouchelogique; unecouchephysique. La couche conceptuelle décrit le réseau de flot de données en termes de processus abstraits indépendantsdeschoixlogicielsetmatériels.lacouchelogiqueplaquesurcesprocessusleschoix logiciels.lacouchematériellerépartitlesprocessussurlagrilleendécrivantlalocalisationdes logicielsquivontconstruirel'applicationglobaledevisualisationcollaborative(voirfigure22). La couche conceptuelle décrit comment les données numériques doivent être transformées en donnéesvisualisables.lacollaborationestdécriteenassociantdesréseauxdeflotsdedonnéesà desutilisateursetenspécifiantlesliensentrecesréseaux.leréseaudeflotdedonnéespeutêtre modifiédefaçondynamiqueenfonctiondel'évolutiondesbesoinsdevisualisationaucoursd'une analyse. Concept Logique Contraintes Placement Physique Figure22:Modèlederéférenceencouches L'utilisation du langage XML pour décrire cette couche doit conduire à une meilleure inter opérabilité des systèmes de visualisation et à un développement plus pertinent des nouveaux logiciels de visualisation (qui pourraient être développés pour inter opérer avec ces nouveaux standards).l'avantaged'utiliserunecoucheconceptuelle(enxml)pourdécrirelesprogrammesde 39/62

40 visualisation (par exemple la façon dont les pipelines graphiques sont construits par les environnementsmodulairesdevisualisation)estd'ouvrirlavoieàdeséchangesdevisualisations entrelesutilisateursdedifférentssystèmes.onnoteratoutefoisquel'éventuelsuccèsd'unetelle spécification formelle estliéàl'émergence progressived'une ontologiedelavisualisationbien décriteetpartagée(ontologie=modèlegénéraloutaxonomiedestypesdedonnéesetdesméthodes ettechniquesdevisualisation[19]). La couche logique peut être réalisée de différentes façons. Par exemple, chaque entité peut correspondre à un module au sein d'une environnement modulaire de visualisation, ou à une fonctiondebibliothèqueouàunecombinaisondesdeux.sileprincipedecettecoucheestdenepas préciser la localisation des exécutions, le choix des logiciels introduit des contraintes sur les ressourcesrequises.depluscescontraintesnesontpasstatiquespuisquedenouvellesdonnées peuvent être mises en jeux lesquelles nécessitent une migration logicielle pour satisfaire des contraintesdeperformance. Aufinallacouchephysiqueinterprètelaspécificationdelacouchelogiqueentermederessources surunenvironnement«grille»particulier.icinonplusleschoixnesontpasstatiques. 6.4 Miseenpratiquedumodèle Chaquecouchedumodèleabesoind'êtrereprésentéepourpouvoirexprimerlesinstancesderéseau mais aussi les transformations d'une couche dans l'autre. Si la plupart des environnements de visualisationmodulaireàbasedeflotsdedonnéesprivilégientuneprésentationpardiagrammes, gvizexploreunmoyendereprésentationàlafoisdiagrammatiquemaisaussibasésurunlangage «skml». La description des modules gviz ressemble àcelle des modules FlowVR, avec des définitionsdeportsd'entréeetdesortie.unsouciparticulierdesconcepteursdegvizaétéde proposer des outils généraux tout en les illustrant avec de véritables environnements de visualisation.c'estdanscetespritqu'ilsontproposéunmoduleirisexplorerquiluipermetdelire lesfichiersskmlpourlancerdessessionscollaborativescovisa.unoutilinversepermetde générer du skml pour exprimer des sessions IRIS Explorer. Le concept est annoncé comme transférableàvtk[60],opendx[38],outoutenvironnementmodulairedevisualisation. Le«g»degVizsignifie«Grille»et,hormislesoucidegénéralité,c'estleprincipalapportdecet environnement.cedernierautorisel'allocationdemodulesenlocalmaisaussiàdistancesurla grille.defaçonévidente,c'estparticulièrementutilepourlessimulationsquigénèrentlesdonnées, maisaussipourlescalculsintensifsdevisualisationtelsquelesextractionsd'iso surfacessurdes données massives. D'autres environnements modulaires de visualisation implantent ce type de distribution mais gviz apporte la technologie «grille» en portant l'effort sur la sécurité, l'authentification, l'identification et la découverte de ressource. Par exemple IRIS Explorer se contentedumécanismedershpourlesappelsdistants,alorsquegvizprivilégiesshouglobus. 6.5 BibliothèquegViz LabibliothèquegVizestcomposéededeuxparties:unepourlepilotagedesapplicationsqui permet d'appareiller le code des scientifiques, l'autre pour autoriser les connexions entre les composants généraux et les codes de visualisations. L'implantation des mécanismes de communication vise à minimiser les interruptions de la simulation. L'architecture fournit des 40/62

41 processuslégerspourrecevoirleschangementssurlesparamètresdepilotageetpourlesconserver dansunequeuejusqu'àcequ'ilssoientrequisparlasimulation.demêmelesystèmefournitdes processuslégersenguisedeserveurspourlesparamètresàdestinationdesclientsconnectéset d'autresprocessuslégerspourfournirlesdonnéescalculées.lasecondegrandefonctionnalitédela bibliothèqueestdefournirdesroutinesd'apipourlesclientsafinqu'ilslesutilisentpourcréerdes communications avec la simulation. L'apport de gviz, vis à vis d'autres environnements de visualisationdedonnéesautorisantlepilotage,estdefournirlesmoyensd'externaliserlasimulation vis à visduprocessusdeflotdedonnées(voirfigure23). Simulation active gviz Paramètres de contrôle Grille Pilotage données gvviz gvviz Contrôle de la Simulation Sélection des données Données vers géométrie Rendu de la géométrie Figure23:UtilisationdegVizpourpiloteretvisualiserdesdonnéesdepuisunesimulation exécutéesurlagrille Lescommunicationsentrelessimulationsetlescodesclientspeuventêtregéréesdedifférentes manières.cesontlesconcepteursdessimulationsquichoisissentlesmodesdecommunicationen choisissantlesméthodes.lemoyenleplussimpleestd'utiliserlessocketsunixmaisceladevrait êtreréservéàunenvironnementsécurisé.l'environnementoffreuneinterfaceaveclesservicesweb vialabibliothèquegsoap.làoùl'accèsestréservéàcertainsmaisoùl'environnementestouvert, dessocketsglobussontfournis.uneversiondesgsoaputiliseunmodulegsiafindegarantir l'authentification.enoutreilestpossibled'adjoindredesmoyensd'encryptagepoursécuriserles transfertsdedonnées. La bibliothèque gviz contient également les outils gvizds et gvizproxy. Le premier est un «directory service» qui collecte l'existence et les modalités de connexion des simulations disponibles.unsystèmegvizpeutainsitrouverlessimulationsencoursd'exécutionencontactant un ou plusieursserveursgvizds.unefoislasimulationdécouverteellepeutêtredirectement contactée.gvisdsestfournisouslaformed'unensembledeserviceswebaccédéviasoap. Unedesdifficultésbienconnuelorsqu'ondoitaccéderàuneressourcedecalculsurlaGrilleest qu'elle est souvent localisée sur un cluster configuré en réseau privé. Il est alors difficile de communiquer directement avec une machine ne disposant que d'une adresse privée. L'outil 41/62

42 gvizproxyréaliseunpontentreprocessusinterneetprocessusexterne.lorsqu'uneapplicationde visualisationcontactegvizdspourtrouverunesimulation,celui ciretournelesmodalitédecontact de gvizproxy au travers duquel il est possible d'accéder à la simulation. La visualisation se connecte alors à gvizproxy comme si elle accédait à la simulation et gvizproxy transfère les donnéesdel'unàl'autre. LesmoyensfournispargVizpermettentderéaliserentièrementàdistanceledéploiementetle pilotagedelasimulationetduprocessusdevisualisationpournegérerenlocalquelesparamètres depilotage,ladéfinitiondupipelineetlerapatriementfinaldesimagesrendues.c'estlescénariode lafigure24.ceschémacorrespondàundémonstrateuroùirisexplorerestutilisécommefront endpourlanceràdistanceuncodedesimulationetunpipelinedetraitementvisueletdepilotage.il estalorspossibledesedéconnecterpouruntempsdelasimulationavantd'yreveniràsaguisepour récupérerlesimagescourantesetajusterlesparamètresdevisualisation. Pilotage Simulation active Grille gviz données geométrie Rendu Paramètres de contrôle gvviz Contrôle de la Simulation Visualisation des images distantes Figure24:Connexiondecomposantsdesimulationsetdevisualisationssurlagrille Leprojetestopensource(dernièrerelease:gViz1.1août2005)etestpoursuiviviale«Integrative BiologyProject»quiestactif(dernierrapportdatantde2006). 7. DIVA9 Lebutinitialdeceprojetestdepromouvoirladéfinitionetl'émergenced'un«standardvirtuel» pourlavisualisationscientifiquehauteperformance.leprojetestissududépartementd'energie Américain(DOE)quiatravaillésurlesalgorithmesetl'infrastructuredevisualisationaprèsavoir constatéquelesproduitscommerciauxnerépondaientpasàsesbesoins.leprojetseperçoitentant que processus complet associant les partenaires dépositaires des besoins en visualisation (en l'occurrencelesprojetsscidacfinancésparledoe)jusqu'àlacommunautédelarecherchesur cedomaineprécis.cesrecherchesportentsurlesalgorithmespropresàlavisualisationdistante ainsiquesurlesinfrastructuresnécessairesauxdéploiementseffectifs. Les promoteurs de DIVA (le DOE) dressent le constat qu'en dépit d'années d'efforts et de 9 vis.lbl.gov/research/diva/index.html 42/62

43 démonstrationsréussiesdevisualisationdistante,lesutilisateursutilisentdefaçonprédominantedes outilsenlocalsurlesstations.aumieuxcesontdesconnectionsviax11surdesoutilsdistants séquentiels.pourtantiln'existepasd'autreissuequelavisualisationdistante/parallèlepourgérerles donnéesactuelles.maislesoutilsoffrentdesfonctionnalitésfractionnairesetleseffortsenmatière devisualisationdistantenelesontpasmoins:certainsoutilssontopensource(parallelvtk, OpenDX), d'autres sont des environnements commerciaux (CEI EnSight, AVS Express) enfin certainssonttotalementintégrés(visit,visapult,terascalebrowser). LespromoteursdeDIVAinsistentsurlemanquedegénéralitédesoutilsexistantsetsurtoutsurle faitquecesarchitecturesn'offrentpasdesolutionexhaustivepourlesarchitecturesparallèleset distribuéesactuelles.commentlesfaireinter opérer?entoutétatdecause,uniquementavecune architecture commune créée à cette fin et conçue pour susciter l'adoption des utilisateurs. Ils proposentdoncdeconstruireunearchitecturerigideinduisantdebonnespratiquesdeconception. Lesystèmedevraitfournirlesmoyensdedéchargerlesdéveloppeursdestâchesdomestiquespour qu'ilsseconcentrentsurlesconcepts. DIVAdevrait: êtremodulairepourintégrerlesdéveloppementscommunautaires; supporterladécouvertederessources; supporterl'analysedeperformanceetl'équilibragedechargeenconséquence; supporterlestreaming,l'out of coreetlesniveauxdedétails; découplerlesmodulesdetraitementetlescodesdeprésentation/gui; intégrerdesmodèlesinternesrobustes; reprendrelescaractéristiquesessentiellesdesoutilsdelacommunautécommeopendx, AVSetVTK; encoderdesstructuresdedonnéesdebaseenvisualisationetscience(décompositionde domaine, représentation hiérarchique, LOD...) afin de mettre fin à la balkanisation des formatsetdesdonnées. Le projet par ces ambitions et son analyse ressemble à gviz. Par contre il semble plutôt en gestationetpeudynamiqueavecdesworkshopsdatantde2003puisuneprésentationaulbl's DistributedSystemsDepartmentennov SciRun/SciRun2 LeSCIInstitutedel'universitédel'Utahapourthèmederecherchegénérallecalculscientifique incluant les aspects visualisation et traitement d'images. Dans ce cadre, il est à l'origine du développement de SCIRun [45], PSE (Problem Solving Environment) dédié aux simulations numériquesetquiintègredesoutilspourlavisualisation.nousavonsvuquelespremierspasvers lavisualisationdistanteontdonnélieuàunprototypeappelésemotusvisumquiapermisuntravail sur la répartition du pipeline graphique. Désormais cet aspect est abordé d'une manière plus généraleavecledéveloppementdescirun2[46]quiestuneapprocheparcomposantsconforme aucca. 43/62

44 8.1 SciRun SCIRunestdéfinicommeunenvironnementdeprogrammationpourlecalculscientifiqueetla visualisation.ilsedéfinitcomme: un ensemble de bibliothèques qui fournissent diverses implémentations de méthodes numériques(solvers,...),deméthodesdeprérenduetderendu, une infrastructure qui permetla création et la gestion de l'applicationvia une interface graphique.uneapplicationestalorsconçuecommeuncanevasdemodulesconnectésentre euxvialeursportsselonlemodèledataflow, unensembledepontsavecdesbibliothèquestrèsutiliséesencalculscientifique(petsc, Matlabviadesscripts). L'utilisationdeSCIRunestbaséesuruneinterfacegraphiquequipermetdeconstruirel'application encréantlecanevasdel'applicationgraphiquementmoduleparmoduleeteninter connectantleurs ports.deplus,unmoduleparticulierpeutêtreutiliséafind'intégrerdelavisualisationdansune application.cemoduleestenfaitunvieweravecseulementdesportsd'entréeconnectésàdes modulesdeprérenduetderenduappliquésauxrésultatsd'unesimulationcommel'illustrelafigure 25issued'untutorielSCIRun10. Figure25:ExempledecanevasdeSciRun SCIRunestdestinéauxarchitecturesàmémoirepartagéeetutilisedoncunparallélismeparthreads. Enintégrantàlafoisdesbibliothèquesdecalculsetgraphiquesiloffreunenvironnementdetravail convivial et qui semble facile à utiliser. Il reste une question sur la facilité d'intégration d'un /62

45 nouveaumoduledecalculougraphiquelorsquel'algorithmevoulun'estpasimplémentédansles bibliothèquesdisponibles. 8.2 SciRun2 Dans[45],lavisualisationdistanteestpointéecommeuneperspectived'améliorationdeSCIRun. Cependant,auvudelacomplexitédesdifférentsscénariospossiblespourlarépartitiondupipeline graphique(similairesànostroisscénarios),ladirectionchoisieestdefaireévoluerscirunenune approcheparcomposantsconformeaumodèlecca. Ainsil'ambitiondeSCIRun2commel'illustrelafigure 2611 estdefournirunmétamodèlepar composantspermettantd'intégrerunensembled'environnementsauseind'unemêmeapplication. Figure26:SCIRun2commemétamodéleparcomposants SCIRun2estdansunpremiertempsuneimplémentationd'uneapprocheparcomposantsdetype CCAintégrantaussilesportsdirectsoucollectifsàpartird'unebibliothèqueappeléeMxN[36]qui formalise les méthodes collectives d'invocation et de distribution de données sur plusieurs composants. De cette manière il définit des composants parallèlesconstituésd'un ensemble de composants dont tous les ports participent à une même opération collective «uses» ou «provides». Ensuite, SCIRun2 permet ou permettra d'intégrer directement des composants CORBA,MicrosoftCOMoudesmodulesVTKdansuneapplicationSCIRun2.Enfin,SCIRun2en tantquemétamodèlesebaseégalementsurdescomposantssupplémentairesappelés«bridges» pourcréerdespontsentredifférentscomposantsn'appartenantpasàlamêmeinfrastructurecca. Un prototype SCIRun2 semble être en cours de développement mais non disponible. Cette approche,encoreunefoisplusgénéralequ'unesolutiondevisualisationdistanteestàsuivrecarses perspectivespourraientenfaireunenvironnementdedéploiementd'applicationstrèsintéressant forum.org 45/62

46 9. Mbender Le projet Mbender12, duvisualization Group dulawrence Berkeley National Laboratory, s'est intéresséauxsolutionsderechangeauxdécompositionstraditionnellessousformedepipelinepour améliorerlavisualisation3dinteractiveàdistance.lebutaffichéestdeproposerunevisualisation entièrement interactive des données 3D variables dans le temps à l'aide "des outils de bureau standard".leprojetpartduprincipequedansbeaucoupdecas,lesutilisateursexigentseulementun sous ensembledetouteslesfonctionnalitéspossiblesdevisualisation.ilssouhaitentsimplement comprendre des rapports entre la forme 3D et la profondeur, et passer en revue des données variablesdansletempsprésentéesdansunformat3d. L'approcheadoptéeestd'explorerdesmanièresdefournirlavisualisationetlesrésultatsderendu d'unefaçonquisimulel'expérienceparl'explorationinteractiveen3d.lemécanismedefourniture àdistancedurendudoittrouverunéquilibreentrelecoûtetlesfonctionnalitésoffertes.l'envoides imagesplutôtquedesdonnéesestunemeilleureapprocheentermed'extensibilitéversdesdonnées toujoursplusgrandes.cependant,l'envoidesimagesestintrinsèquementcoûteuxetl'interactivité souffredèsqu'ilyaunelatencemêmemineuredueauréseau. LechoixdeMbenderestdecréerunfilminteractif3D.Ilproduituncertainnombred'imagesd'une scène4d(3+temps)enchangeantlepointdevue,puisfournitàl'utilisateurlacapacitédechoisir facilement un point de vue ou un pas de temps. De cette façon, l'utilisateur a l'expérience de l'interaction 3D avec des données variables en temps. Cette technique, comme l'ibr, est particulièrementutiledanslecadredelavisualisationscientifiqueàdistancepuisqu'elleestbasée surletransfertdesimagesdontlataillepeutêtrebieninférieureàcelledesdonnées.parcontre, contrairementauxtechniquestraditionnellesd'ibrquitiennentcomptedelacohérenceinterframe pourreconstruiredesimages,cetteapprochesecontentedefournirlesmoyensdeprésenterdes images préexistantes adaptées au point de vue de l'utilisateur. Plusieurs approches alternatives répondentàcesobjectifs:desprimitivesjava script,quicktimevretmbrowser,unnavigateur surdesimagesmulti résolution. Mbendersacrifielagénéralitédesautressolutionsdevisualisationdistantemaisoffredenombreux avantages: Lecoûtdetransfertestbornéparlenombredevuesetlarésolutiondesimagesrenduesqui composentlefilminteractif,pasparlaquantitédesdonnées. Lacapacitéd'exécuterdel'interaction/explorationdesdonnées3Dvariablesentempsen utilisant"lelogicieldebureaustandard",commeunnavigateurwebstandard,oulemodule QuickTimedesordinateursApple. La capacité de fournir une expérience 3D interactive aux utilisateurs à distance indépendamment de l'algorithme, de la technique ou de l'application de visualisation produisantdel'imagerie. Lacapacitédeservirdelavisualisationàdistanceavecunsimpleserveurweb,simplifiant parlàmêmelesproblèmesdeconfigurationdesserveurs,despare feux. Unevisionsimilaireauserviceweb,lavisualisationpeutêtreaccessibleàungrandnombre d'utilisateurspotentiels,ouseulementàquelques uns,enfonctiondeschoixdecontrôles d'accès vis.lbl.gov/research/mbender/ 46/62

47 9.1 EncodeurJavascript Figure27:Visualisationvial'encodeurJavascript UnedespremièresexpériencescitéeduprojetMbenderutiliseJavaScriptpourexécuterducôtédu clientlasélectiond'imagesdynamiquesbaséesurlapositiondelasouris(figure27).c'estprésenté en tant que solution "à faible composante technologique" utilisant n'importe laquelle parmi un certainnombred'applicationsdevisualisationpourproduiredesimagesselonunjeudepointsde vueetstockerlesimagesdansdesfichiersderastérisation.ensuite,"unencodeur"créeunepage webcontenantlesimagesenlienavecunclientjavascriptquisélectionnelesimagesenfonctionde lapositiondelasouris.silespointsdevuesontchoisisdelabonnemanière,alorsl'interfacede Javascript«secomportecomme»unenavigation3Dinteractiveclassique. L'avantage principal de cette approche (via un encodeur en Javascript) est qu'un web browser standardpeutêtreemployépourfairel'interaction3d.ildemeurel'inconvénientquesonutilisation n'estpasraisonnablepourdes«grandesetcomplexes»interactions3d.lejavascriptpré charge d'abordtouteslesimagespourlascènedanslecachedunavigateuravantqu'ilsoitpossibled'agir surlascène.quandlascènecontientunnombrerestreintd'images,cettelimitationestrarementun problème.quand«lefilminteractif»contientungrandnombred'images peut êtrereprésentant beaucoupdepointsdevuefinementespacéspourfournirunebonnefidélitévisuelle alorsilest possiblequelasaturationducacheprovoqueuneerreurdunavigateur.l'approchejavascriptest intéressantepourladiffusiondesrésultats(peut êtrepournaviguerdanslesbasesderésultats), mais son utilisation est relativement limitée pour la visualisation 3D interactive des données importantesentaille. 9.2 QuickTimeVRobjectMovies QuickTimeVRestunlecteurdemédiacrééetmaintenuparApple.C'estunetechnologieinter plate forme,pourmanoeuvrer,augmenteretstockerlavidéo,leson,l'animation,lesgraphiques,le texte,lamusique,ainsiquelavisualisationà360degréspropreàla«réalitévirtuelle».ilpermet 47/62

48 égalementdelireencontinuunfluxvidéonumériqueoùlefluxdedonnéespeutêtrestockéou fourni en continu. Apple sur son site web précise qu'il existe deux types principaux de film QuickTimeVR:les«filmsdepanorama»etles«filmsd'objet».Lesdeuxformessontdesfilmsoù l'imageestdirigéeparl'utilisateur.lesfilmspeuventêtrecréésphotographiquementouavecun logiciel3d.classiquementlesenvironnementsrendussontdesinterprétationsphoto réalistesdela réalité.avecunfilmdepanorama,ilestpossibledetournerà360degrésàpartird'unpointfixe afinderegarderautourdesoi.inversement,lesfilmsd'objet(voirfigure28)sontplusapparentés auregardàl'intérieurd'unbocaldepuisn'importequelledirection.end'autrestermes,onpeut placerlepointdevueàn'importequelendroitsurlasurfaced'unesphèretoutenobservanttoujours lecentredelasphère.lesfilmsd'objetssontcomposésd'unchoixd'imagesdiscrètes:qtvrne faitaucuneinterpolation.sil'ondisposed'ungrandnombred'imagesprisesàdesanglesproche,le mouvementsemblelisse.lefilmd'objetsdeqtvrestuneexcellentemanièredeprésenteren3d lesrésultatsdevisualisationetdepermettreunemanipulationinteractivedesvues.leplayerqtvr autorise également les «zoom in, zoom out», ainsi que la capacité de rembobiner des images variablesdansletemps. Figure28:VisualisationviaQTVR L'avantageimportantparrapportàl'encodeurjavascriptestquelesimagesn'ontpasbesoind'être entièrementstockéesenmémoirepourcommencerlerendu.ellespeuventapparaîtreaufuretà mesureenfonctiondelanavigationtoutenamortissantlalatenceduréseaugrâceàlacapacitéde QTVRd'offrirunenavigation3Dàpartird'imagesenmémoire.Cesystèmeaainsilacapacitéde «cacher» les résultats d'un rendu distant et de les visualiser sur n'importe quelle machine de bureau. LacontributiondeLBNLsurcesujetestlacréationd'unencodeurquiproduitdesfilmsd'objet QuickTime VR.Leprojetsembleavoir rencontrédesdifficultésàtrouverunencodeurqtvr open source. 48/62

49 9.3 Navigationinteractivedansdesimagespré renduesenmulti résolution. Si l'onutiliselezoomdeqtvr,onvoitrapidementqu'ilyaunproblèmeaveclarésolution d'image.pendantlezoom,larésolutionnes'améliorepas.ilseraitpréférabled'offrirlacapacitéde zoomeràdesrésolutionsaussiélevéesquenécessaire.ainsi,desimagesderésolutionplusélevées devraientpouvoirêtrechargéesdansunespacedecacheafind'êtrevisualiséesencasdezoom. Figure29:ImageQTVRlarge Lesfigures 29, 30 et 31 illustrentexactementcepoint.lafigure 29 estlareprésentationlaplus largedel'objet.sil'onzoomeàl'intérieuravecleplayernormaldeqtvr,onobtientuneimage brouilléedonnéefigure 30.Aveclavéritablereprésentationdemulti résolution,onobtientune imagefortementdétailléefigure31 Letravaildemulti résolutionpartdubesoindemaintenir lafidélitévisuelleélevéependantlanavigationinteractive3d.destechnologiessemblables sontnaissantessurleweb,parexemplepourl'achatenligneafindepermettrelezoomsur desdétailsdeproduit /62

50 Figure30:Détailsansmulti résolution Figure31:Détailavecmulti résolution L'architecture(figure32)dusystèmemulti résolutionestbaséesurdesimagespré rendues, parexempleviaopenrmscenegraph[35].lesimages,parpasdetemps,sontprisesde plusieurspointsdevuesetàdifférentesrésolutions;parexemple:400x300,1600x1200et 4000x3000.Ensuitelesimagessontpré traitéespourobtenirunensembledefichiersavec uneconventiondenomsenlienavecdeuxfichiersdeméta données:lefichiercatalogueet lefichiercarte.cesfichierssontplacéssurunserveurweb.leclientchargecesfichiersde méta données puis les images en fonction de la navigation. Le client est ici un code classiqueécritenc++quifaitappelàlatechnologiejni(javanativeinterface)etjnlp (JavaNetworkLaunchingProtocol). Figure32:ChaînedetraitementMulti résolution Ilseraitintéressantd'étendrecesystèmeàdescartesdynamiquescequipourraitélargirle nombredesimagesaccessibles.demêmeonpourraitimaginerdegénérerlesimagesàla voléeensortiedesimulation. 50/62

51 10.CumulVS CumulVS [13] est un système de pilotage et de visualisation de simulations lourdes, de collaboration et de tolérance aux fautes et pannes. Il est développé par Oak Ridge National Laboratory, et supporté par le U.S. Department of Energy (DOE). Il n'est pas destiné à la visualisationdistanteentantqueteletpeutdoncêtreclassifiécommeunsystèmetangentànotre étude. Cependant, dans le cadre du pilotage, il intègre la visualisation comme un outil pour contrôler l'évolution des donnéesen cours desimulation. Dans ce sens, il propose aussi de la visualisationdistante Approche Il s'agit de permettre à plusieurs collaborateurs de connecter/déconnecter dynamiquement un visualiseur(viewer)àunesimulationparallèleenaction Architecture L'architecturereposesurunviewerconnectéàl'application.Cedernierdemandeàvisualiserune portion(ourégion)dudomainedecalculàunefréquencedonnée.laspécificationdesdonnées concerneaussilesfrontièresetlatailledescellules.apartirdecettedemandelesdonnéessont collectéesetenvoyéesauviewer.pours'assurerquecelui ciaunevuecohérente(itération)des données,unmécanismedesynchronisationlâche(sansbarrièreexplicite)estréaliséaprèschaque envoidedonnées. Plusieurscollaborateurspeuventmodifierl'applicationparallèle.Unmécanismeàjetonpermetde maintenirlacohérencedesparamètresdupilotage.desprotocolesdeconsistancepermettentde garantirquetouteslestâchesmodifientlesparamètresàl'unisson. CUMULVS comporte deux parties : une partie applicative et un front end de visualisation. L'applicationpeutêtreconstituéedetoutprogrammeàpassagedemessagesetlefront enddetout systèmedevisualisation(implémentationactuellepvm/avs). L'interfaceutilisateurestassezsimple.Ondoitspécifierdeuxinformationsimportantessoitdécrire lamanièredontlesdonnéessontdécomposéesetdéfinirlesparamètresàpiloter. Pourlacollectedechampsdedonnées,CUMULVSréaliselesopérationssuivantes: leviewerseconnecteinitialementàl'applicationpourrassemblerdesinformationssurles différentschampsdedonnéesetlesparamètres, leviewerdemandelacollectedesdonnéesd'uncertainnombredechampsditsvfg(view fieldgroup), pourchaquevfg,leviewerspécifielaportiondedonnéesàcollecter(visualizationregion); cettezoneestdéfinieentermesd'intervallessuivantlesaxesduvolumeetunetaillede cellule. LadeuxièmefonctionessentielledeCUMULVSestlepilotagedesimulationquiconsisteàpouvoir modifierenlignecertainsparamètresd'uneapplicationpardesprocessusdistants(ouexternes).le 51/62

52 pilotageestinitialiséparunappeldefonctionquiréalisel'équivalentd'unerequêtedechampsde donnéesen établissantuneconnexion synchronelâcheavecl'application. Cettesynchronisation garantitquetouteslestâchesmodifientlesparamètresaumêmemoment. Unefoislepilotageinitialisé,pourmodifierunparamètreparticulier,leviewerdoitacquérirun jetonspécifique.lorsqu'ilalejeton,unviewermodifielesparamètresqu'ilasélectionnésavantde lesrenvoyeràl'applicationetrelâcherlejeton. Pourcertainstypesdesimulationscommelessystèmesàparticules,plusieursinstancesd'unmême objet peuvent être contrôlées différemment. Pour ce type d'utilisation, CUMULVS propose les paramètresindexés.aveccesderniers,unparamètresupplémentaire«index»estajoutéàceuxde l'application.lorsdelarécupérationdesparamètresparl'application,c'estceparamètrequiest extraitenpremierpourconnaîtrel'instanceparticulièred'unobjetàlaquelles'appliquentlesautres paramètres. Lesprogrammesparallèless'exécutentdeplusenplussurdesarchitectureséclatéesethétérogènes. Latoléranceauxfautesetpannesdevientnécessaire.CUMULVSfournitdesoutilspouruntel mécanisme.ainsitouslesmoyensnécessairespourredémarreruneapplicationparallèleéchouée sontencapsulésdansunprocessusséparé,lecpd(checkpointingdaemon).c'estuncheckpointing dirigéparl'utilisateurdanslesensoùc'estleprogrammeurquispécifielesvariablesàsauvegarder etfournitlesmoyensd'indiquersil'applicationdémarrenormalementouàpartird'uncheckpoint. CUMULVS,quantàlui,gèrel'extractionduderniercheckpointcohérentainsiquesonchargement danslesvariablesutilisateur.cetteapprochepermetlamigrationdeprocessus,lescheckpoints stockantsuffisammentd'information. LeCPDs'exécutesurchaquenoeuddelamachinevirtuelle.Ilfournitdeuxfonctionsélémentaires: sauvegarderuncheckpointàpartird'uneapplication chargeruncheckpointdansuneapplication Deux réponses sont possibles en cas d'échec : soit on arrête tous les noeuds et on opère un redémarragecompletaprèschaqueéchec,soitonnotifieauxnoeudsencoreactifsqu'ilsdoivent repartird'uncheckpoint.danstouslescas,c'estlecpdquicontrôlelesignalementetlagestiondes tâchespourredémarrerproprementuneapplicationparallèlequiapartiellementoucomplètement échoué. Lecommitd'uncheckpoint(écritureenmémoirenon volatile)aunsurcoûtimportant.acausedu schémaasynchroneentrelestâches,lorsd'unéchec,siuncheckpointestincompletalorstoutesles tâchesdoiventremontercollectivementauderniercheckpointvalide.suivantlatailledesdonnées danslescheckpoints,celles cisontrépliquéessurchaquenoeudounon. 11.EnvironnementpourlePilotagedeSimulationsNumériques L'environnementEPSNestégalementdédiéaupilotagedesimulationsnumériquesparallèleset distribués.ilestdéveloppéauseind'uneaci GRIDparleprojetScAlApplixdel'INRIAFuturs14. Cetenvironnementaenparticulierfaitl'objetd'unethèse[16] /62

53 11.1 Approche Danslecadredessimulationsnumériquesreposantsurdesprocessusdecalculitératifselonune architecturedetypespmd,l'objectifdecetenvironnementestdepermettreauxutilisateursde piloterunesimulationparlavisualisationdesrésultatsintermédiaires.leprincipedecepilotageest d'insérerdanslasimulationmêmedespointsd'arrêtgérésparuneapiquipermetl'extractiondes donnéesetleurvisualisationsurleclientlocalselonleprincipeillustréfigure Architecture L'architectured'EPSNestbaséesurdesmodélisationsdelasimulationetdupilotagepourgénérer unmodèlehiérarchiqueentâchesquipermettradeconstruirelesinteractionsaveclasimulation. Commelemontrelafigure34,l'utilisateurfournitcesmodélisationssousformed'instrumentation ducodesourceassociéeàunedescriptioncomplémentairexmlprécisantlepilotagec'est à dire lesmodesd'interactionaveclasimulation.unere compilationdel'exécutabledelasimulation, utilisantlesbibliothèquesepsn,permetdefournirunenouvelleversiondite«pilotable»quise déploiesurleserveurdecalculsdemanièreordinairepourl'utilisateur.leclientpourréaliserson pilotageseconnectealorsdynamiquementàlasimulationetpeutluisoumettredifférentesrequêtes commel'accèsàlavoléedesrésultatsintermédiaires,lamodificationàdistancedeparamètresdela simulation.danscesens,l'environnementepsnfournitunclientgénériqueappelé Simone qui permetlaconnexionetl'interactionavectoutessimulationsinstrumentéesparepsn. Interactionàlavolée Réseau sitedistant sitelocal Simulation numérique Outilsde visualisation Réseau Transfertdesrésultatsintermédiaires Figure33:Simulationinteractive(schémareprisde[16]) Encequiconcernelecouplageentrelasimulationetleclientréalisantlepilotage,ilsuitunmodèle parcomposantsparallèles.ainsilasimulationestlepremiercomposantconstituéd'unproxyepsn etd'unensembledeportspourtouslesprocessus.demêmelavisualisationquipeutêtreparallèle constitue le deuxième composant sur le même principe. EPSN fournit alors une couche communication basée sur CORBA pour assurer les transferts de données entre les deux composants.lesrequêtesvialeproxyduclientsontenvoyéesauproxyduserveurdesimulations quilestransmetauxportsdesprocessusdelasimulationquienfinréalisentletransfertparallèledes 53/62

54 donnéesdemandées. Figure34:Lecycledevied'EPSN(schémareprisde[16]) EPSNestdoncplusqu'unoutildevisualisationdistantepuisquesonpremierobjectifestd'offrirles moyens d'interagir avec une simulation. Cependant, le pilotage étant fortement lié à de la visualisationilresteunexemplesignificatifdanslecadreduscénario2(rendulocal)pourlechoix effectuésurlecouplagedetypecorbaentreleserveurdesimulationetleclientquiréalisele pilotage. 12.Cactus Cactusestunenvironnementlibre,modulaireetportablepourledéveloppementcollaboratifde codeparallèlehauteperformancedesimulationsgénérantdesdonnéesmultidimensionnelles[5].il estportableausensoùl'ondoitpouvoircompileretexécuteruncodecactussurn'importequelle plate forme.ilestmodulaireausensoùilestpossibled'écriredesmodulesquiinteragissentviades interfacesstandardssanspourautantconnaîtrelefonctionnementinternedesautresmoduleset évidemmentdanscecastoutmodulepeutêtreremplacédefaçontransparente.comptetenudu publicvisé(physiciens)cactuspossèdedesstructurespermettantunportageaisédecodesanciens (héritage de code Fortran 77). Cactus ne réinvente pas la roue, mais fait un large usage de technologiesexistantes.iln'imposepasunmodèledeprogrammationafindenepashypothéquer l'avenir.ilproposeuneprogrammationparallèleenmodepropremaisrestecompatibleavecles bibliothèques standards de passage de messages. Son mode d'entrée sortie est propre mais compatibleavecdessystèmesstandardstelquehdf.cetenvironnementseveutsimpleàutiliser, biendocumentéetmaintenable. 54/62

55 12.1 Modèle Lemodèleestbasésuruncorpscentral(«flesh»littéralement«lachair»(ducactus))auquelles modules(«thorns»littéralementlesépines(ducactus))fontréférence.lecorpsestécritenc ANSIàdesfinsdeportabilité.Outrelecorps,l'environnementestprincipalementconstituéde modulespourfaireduparallélisme(classiquementmpiousurlagille:globusviampich G),des I/O(FlexIO,HDF5,Panda),delaphysique(driverspourunigrid/ARM(GrACE),solveursPETc), dupilotageàdistanceetdelavisualisationsansparticulièrementprivilégiercettedernière(1d,2d, 3dAmira,AVS,OpenDX).Leslangagesutiliséssontlaissésauchoixdesauteursdesmodules. LecorpsCactusestindépendantdesmodules.Ilsertdebibliothèquedeservicequelesmodules appellent pour avoir des informations ou demander des actions. Chaque module déclare l'implémentationqu'ilassumeetlesdépendancesentremodulessontexpriméesnonpasviades référencesexplicitesàd'autresmodules(cequibriseraitlamodularitédumodèle)maissousla formededépendancesd'implémentation.cechoixpermetderendrelesmodulesinterchangeables. C'estfinalementdelabonnepolitiquededéveloppementassezclassiquepourlesinformaticienset re découverteparlesphysiciensavectoutefoislapossibilitéd'avoirunsupportd'abstractiondela notiond'implémentation. LecorpsCactusestconstituéainsideplusieurséléments: un system Make : avec usage de configurations pour adapter les compilations aux architectures(t3e,irix,osf,linux,nt,etc) uneapipourlesmodulesafinqu'ilspuissentinter opéreraveclecorps unschedulerquiopèresurlesfonctionsoffertesparlesmodules(leschedulingdesroutines ougroupederoutineestdetype:avant/apres/tantque(trèsutilepourlessimulationavec critèredeconvergence)avecunsystèmededétectiond'inconsistance(figure35). unlangagedeconfiguration,ccl,quiexprimecequelecorpsabesoindeconnaîtredes modules(exemple:l'implémentationfournie,l'ordredesroutinesqueleschedulerdoit respecter,variablesàpasserentrelesroutines,paramètres...). 55/62

56 Figure35:flotduprogrammeCactus 12.2 Parallélisme Les«drivers»sontlesseulsmodulesquiaccèdentenpropreàlanotiondeparallélisme.Lesautres yaccèdentvialecorpscactus(flesh).sicesmoduleslesouhaitent,ilspeuventfaireappel,viale corps,àdesfonctionnalitésdesynchronisation,deréductionoud'interpolationfournies,enréalité, pas le «driver».la couche parallèlesous jacente esttransparenteauxmodules, ellepeut être constituéedesocketsoudesystèmesplusévolués.ilestpossibledechoisiruneimplémentationdu parallélismeàlavoléesansrecompiler,justeenchangeantde«driver»,afindetesterlacouche adéquateàl'environnementcourant.les«drivers»gèrentlesproblèmesdedécoupagedesdonnées etderépartitionsdecelles ci Visualisationdistanteetanalysededonnées Celle ci doit permettre, du point de vue Cactus, de se connecter à une simulation en cours d'exécutionpourréduirelestempsd'analysedessortiesdesimulation.lesexpérimentationscitées pointentqu'ilnesertàriend'avoirunevisualisationtropperformantesil'onestbridéparlasortie de simulation. Aussi les concepteurs ont ils décidé d'implanter des outils directement sur les machinesdesimulationoffrantainsiuntraitementdelavisualisationdontlacapacitéestdumême ordredegrandeurquecelledelasimulation.l'autrevoieexploréeviacactusestlaréductiondu volume des données à visualiser en n'exportant qu'un sous domaine. Les données sont sous échantillonnéesavecl'aidedesmodulesd'i/oenparticulieraveclaméthodehdf5.undernière voieestlareprésentationdansdessous dimensions. Danstouslescasdefigurechoisispourlavisualisation,Cactusn'apportequesonmodèlemodulaire et des modules pré réalisés. Il ne constitue pas intrinsèquement un outil spécifique pour la visualisationdistante.parcontre,deparletypedeproblèmequ'ilviseàrésoudre,lesconcepteurs desapplicationscactusontdûproposerdessolutionsdevisualisationdistante. 56/62