User in the loop Supporto al Computational Steering in ambiente di simulazione

Transcript

1 1. Sommario User in the loop Supporto al Computational Steering in ambiente di simulazione Ing. Mario Valle Advanced Visual Systems Strada 4 Palazzo A4 Milanofiori Assago (Milano) Italy mario@avs.it La visualizzazione è uno strumento potente per esplorare nuove idee, comprendere i risultati di una simulazione e per presentare questi ultimi in maniera efficace. Spesso non c è niente di meglio per intuire la soluzione di un problema che presentarlo ad altri. Quindi perché non inserire attivamente l utente nel ciclo "simulazione analisi dei risultati intervento sui parametri di simulazione"? Questa è l idea alla base della Live Visualization (vedere a che punto si è arrivati) e del Computational Steering (cambiare rotta alla simulazione in corso). Advanced Visual Systems (AVS) ha sperimentato una forma di user-in-the-loop in alcune applicazioni per la fluidodinamica. L esperienza acquisita ha evidenziato la necessità di appoggiarsi ad un toolkit (VISIT) di supporto al computational steering la cui sperimentazione è attualmente in corso in collaborazione col CINECA di Bologna. 2. Simulare per comprendere La simulazione ci permette di comprendere fenomeni e processi che sarebbe troppo dispendioso, lento o fisicamente impossibile ricostruire nella realtà. La simulazione non è fine a se stessa: il suo scopo è quello di ottenere una migliore conoscenza di un fenomeno sia a scopi di ricerca che di supporto alla progettazione di nuovi prodotti. Vista l importanza di questi metodi anche in un contesto produttivo, è utile considerare la frase del 1962 di Richard Hamming: The purpose of computing is insight not numbers. Questo è il pensiero che dovrebbe guidarci nella ricerca di strumenti che ci aiutino a trasformare la messe di dati prodotti in informazioni utili. L utilizzo delle capacità di diagnosi della percezione umana, la sua capacità di comprendere schemi ed associazioni ad un livello che spesso precede l attenzione cosciente (preattentive processing) è uno strumento potente a nostra disposizione, ma spesso trascurato. Infatti la visualizzazione, il trasformare dati in immagini, è stata sempre vista solo come postprocessing: qualcosa che si può impiegare alla fine della pipeline di simulazione per produrre una bella presentazione dei risultati del lavoro.

2 3. Visualizzare per comprendere Il dizionario definisce visualizzare come: formare un immagine mentale di qualcosa non visibile, o non presente alla vista o di un astrazione; rendere visibile alla mente o all immaginazione. Nel nostro campo possiamo allargare la definizione fino a comprendere tutte quelle tecniche che, utilizzando il canale della visione umana, permettono di creare quest immagine mentale a partire dai dati prodotti dal calcolo numerico. Basandoci sulla definizione riassumiamo i benefici di queste tecniche in: Visualizzare per verificare: il confronto fra il modello mentale che ci siamo formati su come deve operare un algoritmo e quello derivante dal calcolo reale permette di verificarne la validità in maniera più immediata. Visualizzare per analizzare: il canale della visione è privilegiato perché ha una grande capacità di cogliere regolarità, schemi ed associazioni. Visualizzare per esplorare: spesso il fenomeno che si sta simulando non è totalmente definito e tutto ciò che può scatenare domande e stimolare curiosità facilita e rende possibile scoperte e miglioramenti imprevisti. Visualizzare per assimilare: significa sfruttare l enorme larghezza di banda della visione umana rispetto agli altri sensi ( unità di informazione al secondo rispetto alle 40 della lettura e le 60 della voce) per assimilare grandi quantità di dati. Visualizzare per comunicare: nessun lavoro è fine a se stesso, le informazioni estratte dai dati numerici devono essere presentate per convincere, per stimolare l azione o la nascita di nuove idee. Tralasciamo gli ultimi due utilizzi della visualizzazione, i più noti e quelli usualmente considerati e concentriamoci sull uso della visualizzazione per analizzare i risultati di un calcolo ed esplorare nuove idee. Presentare ad altri dei risultati spesso è l unica maniera, e non solo nella visualizzazione, per ottenere l intuizione di cui parla Hamming. Questo avviene perché scatena domande e solleva curiosità in chi non è così intimamente preso dalla meccanica del calcolo da poter avere una visione scevra da idee preconcette. I migliori risultati spesso si ottengono non ponendo limiti all autonomia e alla curiosità del fruitore. Varie ricerche mostrano che le scoperte più interessanti sono spesso frutto della curiosità di un singolo su un aspetto marginale della propria attività ufficiale. E i risultati e le nuove Data production Data Visualization specifications Synthesize visualization design Visualization system user Interpret displayed data Visualization design Render Visualization display idee vanno ad influenzare il modo di produrre i dati e di presentarli e così via in un ciclo virtuoso. È possibile prendere delle scorciatoie in questo ciclo, integrando Figura 1 Modello del processo di visualizzazione

3 l esperto ed il fruitore direttamente nel ciclo stesso? Sì, e questa integrazione è chiamata in varie maniere come interactive exploration, exploratory analysis, problem solving environments oppure virtual laboratory. Qui la chiameremo semplicemente: user-inthe-loop. 4. User-in-the-loop Nella simulazione ci sono vari esempi di user-in-the-loop, basti pensare ai simulatori di guida e ai videogiochi. In queste applicazioni l utente è sì integrato nel ciclo di produzione dei dati e visualizzazione, ma l obbiettivo non è quello di estrarre delle informazioni, ma di sviluppare delle capacità (guida) o divertirsi e non è questo l obbiettivo primario delle applicazioni di simulazione che stiamo considerando. Per noi user-in-the-loop significa (v. figura 1) mettere in grado l utente di assimilare i dati trasformati in immagini tramite un sistema di visualizzazione per vedere a che punto è arrivato il processo di simulazione (Live Visualization) e di agire sul processo di produzione dei dati stessi per modificarne i parametri (Computational Steering). L architettura standard di un processo di simulazione prevede invece il consumatore alla fine del ciclo: sia che si parli di risultati prettamente numerici, sia di visualizzazioni. Ma questa architettura, seppure collaudata ed ampiamente utilizzata, ha due fondamentali problemi: Tempi di risposta lunghi che impediscono analisi di tipo what-if. Tempo perso in simulazioni inutili per la necessità di modificare i parametri, e quindi di guidare il calcolo, in base ai risultati ottenuti. Il mettere l utente più strettamente nel ciclo può eliminare o ridurre questi ostacoli. 4.1 Live Visualization Il primo passo dell integrazione dell utente nel ciclo comprende i meccanismi di accesso ai risultati della simulazione man mano che vengono prodotti, sia che si parli di risultati parziali, di risultati a precisione via via crescente oppure di time step di un fenomeno con evoluzione temporale. Una migliore interattività e un controllo più intuitivo della simulazione sono i benefici che si ottengono anche fermandosi a questo livello. Non si controlla ancora la produzione dei dati nella simulazione vera e propria, ma si semplificano le modifiche al codice di calcolo che si riducono qui all accesso ai dati prodotti, normalmente sotto forma di file. Una prima forma di steering è la manipolazione diretta degli oggetti grafici, la navigazione nella scena e la possibilità di variare i parametri e la forma degli algoritmi di visualizzazione raffinando interattivamente la visualizzazione stessa. Inoltre, se si facilita l immersione dell utente nei dati, si ottiene da un lato la riduzione delle ambiguità proprie di una visualizzazione 3D e dall altro si ottiene una presentazione ad alto impatto che facilita la comunicazione.

4 Ma creare visualizzazioni immersive è complesso, e non è il fine principale di chi usa calcolo e simulazione per altri obbiettivi. L uso di strumenti adeguati può nascondere questa complessità e permettere lo sviluppo delle applicazioni anche non direttamente sulle macchine dotate di hardware immersivo, il che non è un vantaggio trascurabile. Un esempio è il framework AVS/Express MPE [4] che permette di sviluppare sistemi avanzati di visualizzazione immersiva astraendosi dalle difficoltà di sviluppo insite in questo tipo di applicazioni. 4.2 Computational Steering Il secondo ramo dell integrazione dell utente nel ciclo di lavoro è quello di dargli la possibilità, oltre a vedere immediatamente i risultati della simulazione, di intervenire sul calcolo stesso modificandone i parametri o cambiando totalmente l'obbiettivo della simulazione. Così si ha un feedback immediato che riduce l intervallo fra la modifica dei parametri ed il risultato corrispondente rendendo più evidenti relazioni di causa / effetto. Senza parlare poi della possibilità di rimediare immediatamente ad input erronei ed all insorgere di instabilità o addirittura di interrompere simulazioni inutili. Da ultimo non bisogna dimenticarsi che il sistema deve tenere traccia dello steering fatto per poter a posteriori capire cosa ha portato ad un certo risultato. 4.3 Integrazione Il mondo della simulazione e quello di interazione con l utente (live visualization e input per il computational steering) devono rimanere due mondi separati sia per i differenti tipi di hardware coinvolti, sia per le differenti esigenze. Il vincolo principale è che la simulazione ha sempre priorità e che la presenza o meno di un sistema di visualizzazione non deve inficiare lo svolgimento del calcolo stesso. Inoltre gli interventi sul codice di simulazione devono essere quanto più possibile limitati e trasparenti e non devono minarne la sicurezza ed affidabilità. 5. Prime esperienze In AVS Italia sono state fatte già in passato delle esperienze di integrazione fra codice di calcolo e visualizzazione nell ambito di progetti sviluppati per conto di FiatAvio. Nei primi progetti l inserimento dell user-in-the-loop si limitava al monitoraggio di un report stampato dell errore per passo di calcolo e l unica funzionalità di steering presente consisteva nella Figura 2 Pannello di controllo della simulazione di BladeCool

5 possibilità di terminare la simulazione quando il valore dell errore scendeva al di sotto di un valore giudicato soddisfacente. Per migliorare questo modo di lavorare si era cominciato con l annegare direttamente il codice di calcolo all interno dell ambiente di visualizzazione, ottenendo sì una semplificazione della comunicazione fra i due mondi, ma rendendo anche molto più complicata la manutenzione del puro codice di calcolo. Ciò ha spinto allo studio di un tipo di comunicazione lascamente sincronizzata basata su file per due progetti recenti: BladeCool, per il progetto termico del raffreddamento delle palette di turbina con un metodo iterativo di calcolo dell equilibrio termico. Diversi codici cooperano fra di loro e devono essere lanciati nell ordine corretto (figura 2). Body3D, per il calcolo di camere di combustione. All utente viene presentata la storia dell errore e a richiesta, in maniera asincrona, si possono richiedere e visualizzare i risultati del calcolo. L utente può inoltre fermare la simulazione ottenendo l ultimo risultato calcolato (figura 3). Le lezioni apprese da questa prima esperienza sono che questo tipo di integrazione può essere sufficiente per ottenere un buon ritorno degli investimenti. La produttività dell utente è migliorata a fronte di pochissimi interventi sul codice di calcolo. Ma rimangono delle difficoltà. Le due applicazioni di visualizzazione e calcolo sono Figura 3 Una visualizzazione di Body3D comunque strettamente interdipendenti ed il codice di sincronizzazione è stato sviluppato ad hoc per ogni progetto. Inoltre a fronte di una buona separazione, la sincronizzazione rimane problematica, anche se nella scala dei tempi di calcolo non ha mai dato particolari problemi. Ci siamo convinti che i problemi possono ridursi appoggiandosi per il computational steering su toolkits esistenti; per questo motivo è stata avviata una ricerca e la sperimentazione di questi in situazioni meno critiche rispetto a quelle di un progetto utente reale. 6. Computational Steering Toolkits Escludendo inizialmente toolkits commerciali, ci si è concentrati sui seguenti: CUMULVS (Collaborative User Migration, User Library for Visualization and Steering) [2] sviluppato presso Oak Ridge National Laboratory. Oltre a fornire il supporto per la visualizzazione live ed il computational steering, fornisce meccanismi per costruire applicazioni distribuite in ambiente eterogeneo. SCIRun [3] dell University of Utah che è stato integrato con Matlab.

6 VISIT (VISualization Interface Toolkit) [1] sviluppato presso il Central Institute for Applied Mathematics - Forschungszentrum Jülich è più semplice degli altri due, ed è integrato con AVS/Express per la parte di visualizzazione. Alla fine abbiamo preso in considerazione quest ultimo per la sua semplicità e per l integrazione già esistente con AVS/Express. 6.1 Il toolkit VISIT VISIT è una libreria che supporta lo sviluppo di simulazioni interattive. Fornisce funzioni per stabilire una connessione fra una simulazione ed un server di visualizzazione, per trasferire dati in maniera trasparente fra di essi ed eventualmente per registrare e rivedere in un secondo momento i risultati della simulazione stessa. Dal lato server utilizza AVS/Express come motore di visualizzazione e fornisce bindings per Perl/Tk, C e Fortran. Il codice si trova su [1] e all International AVS Center di Manchester [5]. Il toolkit è stato utilizzato inizialmente per applicazioni all interno del progetto Gigabit Testbed West [6], un banco di prova per la nuova German Gigabit Science Network (G- WiN [7]). Le applicazioni più importanti sono state: FIRE (Functional MRI in real-time), DMMD (Molecular dynamics on massively parallel computers) [8], ParView (Simulation of solute transport in heterogeneous soil-aquifer systems) [9]. VISIT si basa su un architettura client-server (figura 4) in cui la parte di simulazione è client del visualization server. Il toolkit si occupa della comunicazione (su TCP/IP oppure pseudo comunicazione basata su file) e della sincronizzazione. Dal lato server uno strato fornisce l interfaccia con il programma di visualizzazione (incapsulata in moduli di AVS/Express). Figura 4 Architettura VISIT Le API dal lato client sono pensate per essere il più possibile leggere e il meno possibile di disturbo per il codice di calcolo. Assieme al toolkit sono presenti due applicazioni a supporto: un semplice name server (SEAP) che fornisce la possibilità di effettuare la connessione basandosi su service names, e VBroker, uno strumento che permette ad un singolo VISIT client di collegarsi a più servers di visualizzazione. Uno solo dei server alla volta può controllare la simulazione, mentre invece tutti ricevono i dati da visualizzare. VBroker gestisce inoltre la registrazione su file di una simulazione ed il conseguente replay. 7. La sperimentazione in CINECA Il CINECA (Consorzio Interuniversitario per il Calcolo Automatico dell'italia Nord Orientale) di Bologna è un cliente AVS di lunga data con cui sono in corso varie attività in partnership. Il suo laboratorio VIS.I.T (VISual Information Technology) è dotato di un

7 teatro virtuale, il primo in Italia, basato sulle tecnologie SGI Reality Center. Dotato di uno schermo semicircolare permette a 15 persone una visione semi-immersiva. Il teatro è pilotato da una SGI Onyx2 IR con 8 CPU e dotata di 3 pipes grafiche. Il settore Sistemi ad Alte Prestazioni del CINECA supporta l'installazione e l'utilizzo di vari codici high performance, tra cui programmi paralleli di dinamica molecolare classica. La dinamica molecolare permette di simulare un sistema microscopico e seguire la traiettoria degli atomi e delle molecole che lo compongono. Applicazioni tipiche sono il calcolo di densità, pressioni e varie altre quantità ed il calcolo di energie di interazione tra due molecole, per esempio nei problemi di protein docking, ovvero l'interazione tra un enzima ed il suo sito attivo. Uno dei codici più diffusi è GROMACS [10][11][12] disponibile anche in formato sorgente sotto la GNU General Public License. In un particolare utilizzo il codice calcola successive configurazioni della proteina cercando di minimizzarne l energia mentre si adatta al sito di docking. Il programma di calcolo principale (mdrun) gira in batch e non è dotato di nessuna interfaccia utente; si può solo avere un idea del livello corrente di energia della configurazione tramite il programma g_energy lanciato da linea di comando. Figura 5 Dominio C2 della Proteina Kinase C ( ) in AVS/Express La visualizzazione della configurazione degli atomi è stata la scelta più ovvia per l insieme di dati da passare al server di visualizzazione. Per la parte di steering la scelta è stata più difficile; per ora si sono provate due strade: perturbare le posizioni di un atomo per far uscire il calcolo dell energia da un minimo locale e fermare il calcolo se dalla visualizzazione si vede che la proteina ha raggiunto una configurazione che è comunque incompatibile col sito di docking. La visualizzazione in AVS/Express utilizza, oltre ai moduli di VISIT per l acquisizione dei dati dal client di calcolo, moduli per la visualizzazione di strutture molecolari presenti nell applicazione STM (See The Molecule) dell Ohio Supercomputer Center e disponibile presso l AVS International Center [5]. 7.1 Lezioni apprese Un primo insieme di risultati da questa sperimentazione è stato estremamente positivo:

8 L uso di uno strumento consolidato per la parte di visualizzazione (AVS/Express MPE) ha permesso di concentrarci sulla parte di inserimento degli hook per il computational steering piuttosto che sulla parte di visualizzazione. Il teatro virtuale ha avuto un grande successo nella presentazione dei risultati sia per le dimensioni dello schermo, sia per la potenza della parte grafica della macchina SGI. La separazione fra calcolo e server di visualizzazione permette di non bloccare l accesso e l utilizzo di una risorsa importante come il teatro virtuale. Ma c è anche un rovescio della medaglia: Il senso di immersione nei dati non è stato così utile come sembrava, soprattutto perché è ancora in corso di installazione il sistema di head tracking ed il wand. La necessità di accedere al codice sorgente del programma di simulazione, anche se semplificato dal toolkit VISIT, richiede comunque la conoscenza approfondita del codice. Oltre a questo si deve scegliere fra varie opzioni per quel che riguarda i differenti livelli di steering possibili e la granularità delle variabili da accedere e modificare. È difficile far assimilare agli utenti la necessità di diventare parte integrante del loop e non rimanere solo spettatori; e ciò purtroppo fa retrocedere il teatro virtuale ad un mero luogo di presentazione. Poiché le simulazioni vengono sottomesse alle macchine di calcolo (SP3 IBM oppure SGI Origin 3800) tramite code, si perde il controllo del momento in cui si può interagire col programma di calcolo. Altre problematiche che potranno dare problemi in futuro riguardano l importanza dell infrastruttura di comunicazione (latenza e bandwith) per l interattività e la rarità di strutture (sale virtuali, CAVE e similari) in cui poter esportare l esperienza fin qui svolta. 7.2 Futuro In futuro pianifichiamo di muoverci lungo due direzioni: il miglioramento del toolkit VISIT e lo studio delle caratteristiche del codice di simulazione utili per facilitare l integrazione in un ambiente di computational steering. Pensiamo di migliorare le caratteristiche di VISIT nel campo della sicurezza in modo da rendere possibile il suo uso in applicazioni di produzione e renderlo anche utilizzabile da clients PC Windows più economici. 8. Riferimenti [1] [2] [3] [4] (AVS/Express in generale) e (AVS/Express MPE)

9 [5] [6] [7] [8] N. Attig, M. Lewerenz, G. Sutmann and R. Vogelsang DMMD - A modular molecular dynamics program for MPP - systems. Proceed. of the 5th European SGI/CRAY MPP - workshop, Bologna, [9] [10] [11] Berendsen, H.J.C., van der Spoel, D. and van Drunen, R. GROMACS: A message-passing parallel molecular dynamics implementation. Comp. Phys. Comm. 91 (1995), [12] Lindahl, E., Hess, B. and van der Spoel, D. GROMACS 3.0: A package for molecular simulation and trajectory analysis. J. Mol. Mod. 7 (2001)