Design of Component-based Parallel Image Processing Libraries in a GRID environment

1
Design of Component-based Parallel Image
Processing Libraries in a GRID environment

• Proposta di tesi di Dottorato
• XIX ciclo
• Candidata Antonella Galizia
• Relatori Andrea Clematis
• Vittoria Gianuzzi

2
Obiettivo

• Il nostro obiettivo è la definizione di strumenti
  per image processing
• High performance
• Distribuiti
• Per raggiungere questo scopo abbiamo individuato
  3 linee di ricerca
• La costruzione di una libreria parallela
• Lintegrazione su piattaforme distribuite
• La costruzione di oggetti paralleli che sfruttino
  tali architetture

3
Sommario

• Scenario
• Computational Grid
• Parallel component based programming tools and
  environments
• Dominio di applicazione Image Processing
• Il nostro percorso
• Una libreria parallela per Image Processing
• Integrazione in ambienti distribuiti
• Evoluzioni alle griglie
• Proposte e conclusioni

4
Scenario

• Computational Grid
• Cosè Grid, Middleware, altri approcci
  distribuiti CORBA
• Parallel component based programming tools and
  environments
• CCA framework
• Structured parallel programming environment
• ASSIST
• Dominio di applicazione Image Processing

5
Scenario

• Il punto di partenza
• La ricerca scientifica si sviluppa sempre di più
  attraverso collaborazioni distribuite,
  utilizzando Internet come piattaforma abilitante
• Si richiedono enormi quantità di dati, capacità
  di elaborazione, sistemi di visualizzazione ad
  alte prestazioni
• Tali risorse sono disponibili grazie alla
  condivisione attraverso linfrastruttura di rete
• Esiste la possibilità di scalare in termini di
  potenza di calcolo, dati, banda di comunicazione

6
Scenario

• Cosè il Grid
• Un ambiente persistente in cui le applicazioni
  possono integrare ed utilizzare risorse
  computazionali, dati, device, e reti appartenenti
  a diverse organizzazioni ed in diverse locazioni
• La condivisione di risorse è ottenuta attraverso
  accessi diretti da parte degli utenti e gli
  accessi alle risorse vengono altamente
  controllati
• Un gruppo di utenti o organizzazioni regolati da
  una politica di condivisione formano le così
  dette virtual organization

7
Scenario

• Una Virtual Organization (VO) è costituita da
• un insieme di individui o istituzioni
• un insieme di risorse da condividere
• un insieme di regole per la condivisione
• Una VO è una collezione di utenti che condividono
  risorse per laccesso a risorse di calcolo e a
  dati distribuiti e perseguono obiettivi comuni.
• Concetto chiave labilità di negoziare le
  modalità di condivisione delle risorse tra i
  componenti di una VO (providers and consumers) ed
  il successivo utilizzo per i propri scopi.
  I.Foster

8
Scenario

• I problemi che il Grid vuole risolvere...
• Il Grid ha una valenza molto pragmatica
• Nasce dallinformatica applicata
• Si focalizza sul permettere un nuovo tipo di
  applicazioni
• Investire nel Grid trova motivazioni nella
  promessa di nuove capacità, non soltanto
  nellinformatica ma anche in altri settori
• Contesto Applicativo
• Finanza
• Industria
• Servizi

9
Scenario

• Quale tipo di applicazioni?
• Computational intensive
• Simulazioni interattive (climate modeling)
• Simulazioni e analisi su larga scala (formazione
  di galassie, campi gravitazionali, previsione di
  terremoti)
• Ingegneria (parameter studies, linked component
  models)
• Data intensive
• Analisi di dati sperimentali (high-energy
  physics)
• Image analysis (astronomia, climatologia,
  ecologia, )

10
Scenario

• Quale tipo di applicazioni?
• Collaborazioni distribuite
• Strumenti online (microscopi, x-ray devices,
  etc.)
• Visualizzazione in remoto (studi climatologici,
  biologia)
• Ingegneria (large-scale structural testing,
  ingegneria chimica)
• E tutti problemi tali da richiedere la
  collaborazione di persona appartenenti a diverse
  organizzazioni e la condivisione di risorse di
  calcolo, dati, strumenti

11
Scenario

• Problematiche relative alle griglie
• Security
• Monitoring/Discovery
• Computing/Processing Power
• Moving and Managing Data
• Managing Systems
• System Packaging/Distribution

12
Scenario

• Come ciò si ottiene nella realtà
• Le implementazioni si ottengono mediante mix di
• Codice specifico dellapplicazione
• Middleware e servizi
• E.G. Globus Toolkit
• Tool e servizi provenienti dalla Grid community
  (spesso compatibili con GT)
• Tenuti insieme da
• Lo sviluppo di applicazioni
• Lintegrazione di sistemi

13
Scenario

• Mettendo tutto insieme si arriva alla
• Open Grid Service Archtecture OGSA

• Definisce unarchitettura service-oriented
• elemento chiave per uneffettiva virtualizzazione
• per soddisfare richieste vitali del Grid
• sicurezza, on-demand, gestione del sistema,
  cooperazioni, etc
• costruito con Web service.
• estendone gli standard quando necessario

14
Scenario

• Nella visione OGSA le librerie scientifiche
  continuano ad avere la loro funzione
• Strumenti performanti per aiutare lutente
• Incapsulano esecuzioni parallele
• Sfruttano le gerarchie di memoria
• Applicano politiche di Load balancing
• Devono essere portate su griglie! GrADS -gtVGrADS
• Sei sperimentazioni ScaLAPACK, Cactus, etc
• Altri studi sono rivolti allinterazione tra
  librerie, compilatori e lambiente dinamico

15
Scenario

• Altra strada per fornire i servizi OGSA è
  rappresentata dai Portali
• Forniscono servizi tramite web browser
• Fungono da gateway tra utente e servizi
• Un Grid Portal è un punto daccesso per un utente
  ad un sistema Grid
• Fornisce il link per tutte le componenti delle VO
• Permette un ulteriore livello di astrazione

La nostra idea è sviluppare un portale Grid per
Image Processing, utilizzando il Portal Toolkit
GridSphere
16
Scenario

• Portali
• Fornisce un ambiente in cui un utente
• Accedere alle risorse
• Eseguire e monitorare le applicazioni
• Collaborare con altri utenti
• Sviluppare delle proprie applicazioni
• Lelemento chiave sono le portlet, contenitori
  che gestiscono i servizi Grid, che sono
  visualizzati in finestre del browser

17
Scenario

• Altri approcci per la realizzazione di middleware
  per architetture eterogenee
• Common Object Request Broker Architecture
• CORBA
• Costituisce un framework orientato agli oggetti,
  dove questi interagiscono superando limitazioni
  quali
• eterogeneità
• locazione
• interoperabilità
• integrazione

La nostra idea è integrare oggetti CORBA in un
ambiente Grid-aware
18
Scenario

• Definito dallObject Management Group OMG, CORBA
• Permette di manipolare componenti software in
  maniera trasparente rispetto alla loro locazione
• Risulta indipendente dal linguaggio di nativo
  degli oggetti, dalle architetture sottostanti (hw
  so)
• Le componenti sono viste come scatole nere che
  offrono o richiedono dei servizi, resi noti
  mediante le interfacce

19
Scenario

• CORBA
• Per la scrittura delle interfacce CORBA-IDL,
  Interface Definition Language
• meta linguaggio di due importanti proprietà
• indipendenza dal linguaggio di implementazione
  delloggetto
• proprietà di eredità delle interfacce
• L ORB vero e proprio canale di individuazione,
  comunicazione e interazione degli oggetti

20
Sommario

• Scenario
• Computational Grid
• Parallel component based programming tools and
  environments
• Dominio di applicazione Image Processing
• Il nostro percorso
• Una libreria parallela per Image Processing
• Integrazione in ambienti distribuiti
• Evoluzioni alle griglie
• Proposte e conclusioni

21
Scenario

• Computational Grid
• Cosè Grid, Middleware, altri approcci
  distribuiti CORBA
• Parallel component based programming tools and
  environments
• CCA framework
• Structured parallel programming environment
• ASSIST
• Dominio di applicazione Image Processing

22
Scenario

• Architetture a componenti
• Lidea costruire programmi componendo
  sotto-moduli applicativi di alto livello
• Esistono molti buoni esempi
• Classici
• MS COM, SciRun I, Java Beans, OMG COM
• Di seconda generazione
• Corba CCM, ASSIST, MS .NET, ProActive, Grid
  Services

23
Scenario

• Common Component Architecture CCA
• Nato nella metà degli anni 90
• Definisce una specifica per lo sviluppo di
  componenti per applicazioni parallele e
  distribuite
• Il CCA Forum
• Circe 100 persone di 20 laboratori di ricerca e
  università americane
• Quattro implementazioni esistenti
• SciRun II
• Ccaffeine
• Decaf
• XCAT

Una delle possibilità è di esplorare lutilizzo
di Ccaffeine per ottenere componenti CCA per
lImage Processing
24
Scenario

• Concetti base CCA
• Porte interfacce pubbliche che definiscono
• Provides ports - diversi servizi che una
  componente fornisce
• Uses ports - diversi servizi che una componente
  richiede

Uses Ports
Provides Ports
25
Scenario

• Concetti base CCA
• Costruire applicazioni mediante composizione di
  componenti
• Connettere le porte uses con le porte provides

26
Scenario

• Ambiente per la programmazione parallela
  strutturata
• A Software development System based upon
  Integrated Skeleton Technology ASSIST
• E un ambiente di sviluppo di applicazioni
  portabili parallele e distribuite
• Coniuga component technology e structured
  parallel programming technology

La nostra idea è utilizzarlo sia per incapsulare
codice che per scrivere componenti parallele per
Image Processing
27
Scenario

• ASSIST
• Skeleton istanza di forme di parallelismo
• Definisce un nuovo costrutto parallel module,
  parmod
• Può essere considerato uno skeleton generico
  espressione di nuove forme di parallelismo
• Un programma ASSIST è un grafo
• Nodi componenti (parmod, sequenziali)
• Archi interfacce astratte che supportano gli
  stream

28
Scenario
ASSIST Il parallel module è definito dai seguenti
elementi

• Stream di Input
• Stream di Output
• Oggetti esterni

• Processori Virtuali
• Topologia
• Stato interno

29
Sommario

• Scenario
• Computational Grid
• Parallel component based programming tools and
  environments
• Dominio di applicazione Image Processing
• Il nostro percorso
• Una libreria parallela per Image Processing
• Integrazione in ambienti distribuiti
• Evoluzioni alle griglie
• Proposte e conclusioni

30
Scenario

• Computational Grid
• Cosè Grid, Middleware, altri approcci
  distribuiti CORBA
• Parallel component based programming tools and
  environments
• CCA framework
• Structured parallel programming environment
• ASSIST
• Dominio di applicazione Image Processing

31
Scenario

• LImage Processing
• Disciplina divenuta un argomento di interesse per
  la comunità scientifica
• Molti ed importanti settori applicativi che hanno
  esigenze di high performance
• Medicina
• Osservazione terrestre
• Trasporti
• Commerciali
• È una di quelle discipline che richiedono
  unapertura al Grid

32
Sommario

• Scenario
• Computational Grid
• Parallel component based programming tools and
  environments
• Dominio di applicazione Image Processing
• Il nostro percorso
• Una libreria parallela per Image Processing
• Integrazione in ambienti distribuiti
• Evoluzioni alle griglie
• Proposte e conclusioni

33
Il nostro percorso

• Una libreria per Image Processing
• Studi preliminari
• Parallelismo
• sperimentazioni
• Una libreria esistente
• Impostazione
• Politiche di ottimizzazione
• Integrazione in ambienti distribuiti
• CORBA
• ASSIST
• Evoluzioni alle Griglie
• Portale
• ASSIST
• Oggetti paralleli performanti

34
Il nostro percorso

• Studi preliminari
• Per la catalogazione delle operazioni abbiamo
  considerato
• G.X. Ritter, J.N. Wilson, Computer vision in
  Image Algebra, CRS Press, 2000
• dove si assume che un numero limitato di classi
  di operazioni ricoprono il nucleo delle
  operazioni comunemente applicate

35
Il nostro percorso

• Studi preliminari
• Per rispondere allesigenza di high performance
  si è deciso di adottare il parallelismo
• La forma che si sposa bene con limage processing
  è il data parallelism
• Vogliamo fornirlo in maniera trasparente
• nascosto allutente - linterfaccia è sequenziale
  ed il parallelismo è gestito dalla libreria
• Vogliamo applicare politiche di ottimizzazione
  delle prestazioni

36
Il nostro percorso

• Studi preliminari
• Individuate le classi di operazioni
• abbiamo delineato parallelizzazione
• più efficiente
• Parellelizzable pattern
• One-to-one
• One-to-M
• One-to unknown
• Composto tali pattern

37
Il nostro percorso

• Studi preliminari
• Per cui ad esempio unoperazione di riduzione
• Max
• Min
• Prod
• Somma

38
Il nostro percorso

• Studi preliminari
• oppure unoperazione di convoluzione
• Notiamo le ghost region
• Le diverse modalità di comunicazione
• I diversi pattern messi insieme

39
Il nostro percorso

• Studi preliminari
• Sono portate avanti varie sperimentazioni
• Strutture dati
• Distribuzione dei dati
• Statica
• ScaLAPACK
• Pre-distribuzione
• Bilanciamento del carico di lavoro
• Ottimizzazioni
• Intra-operation - singole operazioni
• Inter-operation - comunicazioni

40
Il nostro percorso

• Limpostazione del codice
• Fase di calcolo, 4 componenti logiche
• Operazioni sequenziali, agenti 6 livelli da
  operazioni su pixel a trasformazioni geometriche
• Estensioni parallele, funzioni MPI-based
• Operazioni parallele, concatenazione di funzioni
  appartenti ai 2 precedenti moduli
• Api, interfaccia che rende il parallelismo
  trasparente

41
Il nostro percorso

• Limpostazione del codice
• Ottimizzazione del codice, 2 direzioni / 4
  componenti
• Ottimizzazione delle singole function
• Modello di performance per ogni operazione
• Benchmarking tool per il calcolo dei precedenti
  valori
• Ottimizzazione delle chiamate alla libreria
• Specifica dellalgoritmo per lottimizzazione
  inter-operation
• Scheduling per lottimizzazione intra-operation

42
Il nostro percorso
Impostazione del codice
43
Il nostro percorso

• Una libreria esistente
• ParHorus, scritta dal Dr. Frank J. Seinstra,
  Università di Amsterdam
• Implementata in C ed MPI, si basa sullidea di
  parallelismo trasparente
• Linterfaccia è sequenziale
• Il parallelismo è gestito dalla libreria
• La libreria si dirama in due diverse direzioni
• Fase di calcolo
• Ottimizzazione del codice

44
Il nostro percorso

• ParHorus, Lazy Parallelization
• Parallalizzaziona di default modello di
  ottimizzazione
• Si basa sulla definizione di Macchina a stati
  finiti
• Set di stati
• Funzioni di transizione
• Ogni comunicazione o operazione di gestione della
  memoria è ridondante fin quando non sia
  accertato il contrario
• Tali operazioni sono permesse se e solo se la
  loro eliminazione porta una rappresentazione
  invalida

45
Il nostro percorso
Lazy Parallelization esempio

• C A f(A)
• Importare limmagine A
• Applicare ad A loperazione unaria per ottenere
  limmagine B
• Applicare ad A e B loperazione binaria per
  ottenere limmagine C
• Esportare C
• Cancellare tutte le immagini

Operazione Default Lazy
46
Sommario

• Scenario
• Computational Grid
• Parallel component based programming tools and
  environments
• Dominio di applicazione Image Processing
• Il nostro percorso
• Una libreria parallela per Image Processing
• Integrazione in ambienti distribuiti
• Evoluzioni alle griglie
• Proposte e conclusioni

47
Il nostro percorso

• Una libreria per Image Processing
• Studi preliminari
• Parallelismo
• sperimentazioni
• Una libreria esistente
• Impostazione
• Politiche di ottimizzazione
• Integrazione in ambienti distribuiti
• CORBA
• ASSIST
• Evoluzioni alle Griglie
• Portale
• ASSIST
• Oggetti paralleli performanti

48
Il nostro percorso

• La libreria come una componente
• Approccio modulare e flessibile che permetta di
  nascondere la complessità
• Il codice dovrà essere racchiuso in opportuni
  involucri (componenti) che potranno dare luogo ad
  una gerarchia di componenti
• Verrà elaborata una politica di scheduling dei
  processi e delle risorse
• Rimane la politica di ottimizzazione della
  libreria

49
Il nostro percorso

• A tal fine un passo fondamentale è la definizione
  una gerarchia di oggetti
• le più comuni operazioni di image processing
• rappresenti la struttura da integrare nei vari
  ambienti
• da cui estrapolare linterfaccia
• Passi per definire tale gerarchia
• partire dalle strutture dati e relative
  operazioni di manipolazione
• considerare le operazioni che elaborano le stesse
  strutture dati
• raggruppare le operazioni con comportamento simile

50
Il nostro percorso
La gerarchia di oggetti

• Alle strutture dati abbiamo associato le
  operazioni di base

createKernel1d deleteKernel1d createKernel2d de
leteKernel2d createKernel deleteKernel createFr
omData
createMatrix deleteMatrix translate2d scale2d
rotate2d reflect2d copy
createImage deleteImage createImageOnOne copyIm
age readFromFile writeFromFile
51
Il nostro percorso

• La gerarchia di oggetti
• le operazioni sono raggruppate in classi,
  strutture dati

52
Il nostro percorso

• La gerarchia di oggetti
• Raggruppano operazioni con comportamento simile

53
Il nostro percorso

• La gerarchia di oggetti
• Loggetto operazioni

54
Il nostro percorso

• La gerarchia di oggetti
• Lultimo livello è loggetto libreria

55
Il nostro percorso

• Una volta definita tale gerarchia, il primo passo
  compiuto è lintegrazione in CORBA
• Standard per il wrapping di applicazioni
• Il vero problema implementativo è legato alla
  convivenza dei due ambienti MPI-CORBA
• Sistemi che risolvono problemi diversi, quindi
  non dotati di intrinseca compatibilità
• Non esistono schemi prestabiliti per la loro
  convivenza

56
Il nostro percorso

• Lidea più naturale è quella di far coordinare i
  due mondi da un processo che fungerà da gateway
• Server CORBA
• Root MPI
• permettendo in questo modo una gestione
  consapevole della computazione

57
Il nostro percorso

• Il Server fornisce i proprio servizi attivando
  lambiente MPI e gestendolo in maniera opportuna
  e coerente rispetto al mondo CORBA
• Il Server viene mandato in esecuzione mediante un
  mpirun, in cui avremo specificato un numero
  definito di processi MPI
• Tra questi solo il processo di Root attiva lORB
  diventando Server e raccogliendo le richieste

58
Il nostro percorso

• Una volta ottenute le richieste da un Client il
  Server le passa agli altri processi MPI ed
  insieme le eseguono
• Finita la computazione il Server-Root, chiude il
  mondo MPI, raccoglie i risultati e li fornisce
  al Client
• Il punto fondamentale è la comunicazione da parte
  del Server agli altri processi MPI delle
  richieste del Client

59
Il nostro percorso

• Lintegrazione si ottiene mediante la costruzione
  e gestione di canale di comunicazione dei dati
  tra CORBA ed MPI
• Per cui il lavoro del Server è
• Ottenere le richieste dal Client e passarle agli
  altri processi MPI
• Trasmettere i dati relativi alle richieste
• Coordinare lesecuzione
• Passare i risultati al Client

60
Il nostro percorso

• Il punto della situazione
• Diverse funzione della libreria sono state
  integrate in CORBA
• La soluzione adottata funziona
• attualmente stiamo sviluppando unapplicazione
  per valutare
• Le performance
• Scalabilità
• Loverhead

Parallel Image Processing Server
61
Il nostro percorso

• Il prossimo passo previsto è ASSIST
• Integrazione della libreria (breve termine)
• Sviluppo di una libreria (lungo termine)
• Integrazione della libreria
• Anche in ASSIST lintegrazione di codice è molto
  semplice
• Anche qui i problemi sono legati alla presenza di
  MPI nella computazione
• ASSIST ed MPI gestiscono entrambi il
  parallelismoma in maniera diversa ed
  intrinsecamente incompatibile!

62
Il nostro percorso

• Passare attraverso CORBA
• ASSIST permette lutilizzo di oggetti esterni
  compatibilmente con le interfacce e metodi che
  essi mettono a disposizione
• Fornisce la definizione di una interfaccia ORB,
  chiamata assist_orb, per la connessione e
  lutilizzo di oggetti CORBA
• ASSIST è perfettamente integrato nel mondo CORBA
• Considerare la libreria come un Server CORBA, il
  cui scopo è quello di ricevere le richieste ed i
  relativi dati di input da un modulo ASSIST e di
  restituirgli i risultati prodotti

63
Il nostro percorso

• Passare attraverso CORBA
• I vantaggi di questa scelta derivano dalla già
  avvenuta integrazione delle architetture
  ASSIST-CORBA
• Tutte le difficoltà si spostano sul wrapping in
  CORBA
• Già effettuato e quasi concluso!
• Nessuna modifica agli ambienti
• Mantiene la rappresentazione di grafo
• Utilizzo delle politiche di ottimizzazione
• Livello libreria
• Livello ASSIST
• È portabile su griglia

Otteniamo così un primo modulo ASSIST per Image
Processing Grid-aware
64
Sommario

• Scenario
• Computational Grid
• Parallel component based programming tools and
  environments
• Dominio di applicazione Image Processing
• Il nostro percorso
• Una libreria parallela per Image Processing
• Integrazione in ambienti distribuiti
• Evoluzioni alle griglie
• Proposte e conclusioni

65
Il nostro percorso

• Una libreria per Image Processing
• Studi preliminari
• Parallelismo
• sperimentazioni
• Un libreria esistente
• Impostazione
• Politiche di ottimizzazione
• Integrazione in ambienti distribuiti
• CORBA
• ASSIST
• Evoluzioni alle griglie
• Portale
• ASSIST
• Oggetti paralleli performanti

66
Il nostro percorso

• In questa fase
• Portale Grid per lelaborazione di immagini
• Integrazione delle operazioni di Image Processing
  in Web Services
• Costruzione di portlet per la gestione dei
  servizi di griglia
• ASSIST - costruzione di una libreria nativa
  dellambiente
• Analisi dei parmod
• Politiche di scheduling
• Bilanciamento del carico di lavoro
• Possibilità di utilizzare Ccaffeine per la
  costruzione di una componente CCA per lImage
  Processing

67
Il nostro percorso

• In questa fase
• Oggetti paralleli per lImage Processing
• sfruttino al meglio linfrastruttura sottostante
• interagiscano dinamicamente con le griglie
• Verranno investigate politiche di ottimizzazione
• scheduling dei processi e delle risorse
• ottimizzazione delle applicazioni - tuning
  executions
• per esempio cluster omogenei condivisi -gt griglie
  eterogenee

68
Sommario

• Scenario
• Computational Grid
• Parallel component based programming tools and
  environments
• Dominio di applicazione Image Processing
• Il nostro percorso
• Una libreria parallela per Image Processing
• Integrazione in ambienti distribuiti
• Evoluzioni alle griglie
• Proposte e conclusioni

69
Conclusioni

• Risultati ottenuti rispetto alle linee di ricerca
  delineate negli obiettivi
• Costruzione di una libreria parallela per Image
  Processing
• Integrazione della libreria in ambienti
  eterogenei e distribuiti
• Costruzione di nuovi oggetti paralleli per Image
  Processing che sfruttino al meglio le nuove
  tecnologie
• Work Plan
• Progetti e collaborazioni

70
Conclusioni

• Risultati ottenuti - Libreria
• Definizione delle operazioni e gerarchia degli
  oggetti
• Parallelismo - pattern -
• Sperimentazioni per la costruzione della libreria
• Strutture dati
• Distribuzione dei dati
• Bilanciamento del carico di lavoro
• Ottimizzazioni
• Intra-operation - singole operazioni
• Inter-operation - comunicazioni

71
Conclusioni

• Risultati ottenuti - integrazione
• Server CORBA
• Lavoro praticamente finito
• Studi relativi ad ASSIST
• Soluzione adottata CORBA, quasi raggiunta
• Risultati ottenuti - Grid
• Portale studi preliminari del settore
• Web services
• portlet

72
Conclusioni

• Work plan - breve termine
• Costruire lapplicazione per CORBA
• Miglioramento di immagini mediante istogramma
• Applicazione immagini biomediche
• Effettuare test e chiudere il lavoro
• Integrare il Server in ASSIST
• Costruzione del Portale
• Integrazione del codice in Web Services
• Costruzione della portlet per la gestione

Fine gennaio
Non più di due mesi
In questanno!
73
Conclusioni

• Work plan - breve termine
• Costruire la libreria
• Testare MPI 2
• Implementare le operazioni e la gerarchia di
  oggetti
• Work plan - lungo termine
• Costruire una libreria in ASSIST
• Costruire una componente in Ccaffeine
• Studi di ottimizzazione
• Scheduling
• Tuning execution

In questanno!
Lanno prossimo!
74
Conclusioni

• Collaborazioni e progetti
• In fase del tutto embrionale
• Prof. P.Boccacci, Università di Genova
• Sviluppo di unapplicazione per la desfocatura di
  unimmagine SPECT 3D
• J. Novotny, A. Eistein Institut, GridSphere
  project
• Supporto per lo sviluppo del Portale

75
Conclusioni

• Progetti
• MURST 5 - 1999 Grid Computing tecnologie
  abilitanti e applicazioni per eScience
• MURST 5 - 2000 Piattaforma Distribuita ad Alte
  Prestazioni
• Progetto FIRB PIATTAFORME ABILITANTI PER GRIGLIE
  COMPUTAZIONALI A ELEVATE PRESTAZIONI ORIENTATE A
  ORGANIZZAZIONI VIRTUALI SCALABILI, GRID.IT