1Workshop SCoPE, 21-2-2008

L. Merola e S. Pardi

INTEROPERABILITA’ TRA I PROGETTI DELL’AVVISO 1575/2004

STRATEGIE E STATO DELL’ARTE

2

12/02/2007: Primo Concertation Meeting dei progetti dell’Avviso 1575

Favorire una proficua sinergia finalizzata a delineare la struttura portante dell’ infrastruttura GRID nazionale che presenti fattori manifesti o latenti di attrattività per il sistema industriale.

Creare nell’ambito del sito web del PON Ricerca una community web dedicata all’Avviso 1575/2004.

Attivare un Tavolo Tecnico a cui demandare la definizione di un programma volto a supportare l’ interoperabilità tra i 4 progetti cofinanziati.

Aprire ad altri soggetti che operano in ambito GRID per promuovere un proficuo interscambio nazionale ed internazionale.

3

12/05/2007: Avvio del Tavolo Tecnico sull’interoperabilità

Azioni:Azioni:Realizzare, in più steps, l’integrazione e il consolidamento operativo delle risorse informatiche predisposte dai progetti finanziati con le risorse assegnate dall’Avviso 1575 in una comune e-Infrastruttura meridionale integrata a livelloitaliano ed europeo,con particolare riguardo a:

- Miglioramento della connettivita’ interna tra le sedi in OB1 ed esternaverso l’e-Infrastruttura nazionale.

- Definizione e realizzazione di comuni condizioni operative con Service Level Agreement e policies d’interoperabilita’ concordate a livello interno e con le e-Infrastrutture di riferimento nazionale ed europeo.

- Miglioramento ed evoluzione coordinato dei servizi di middleware secondo le necessità di comuni applicazioni all’interno del quadro di riferimento nazionale ed internazionale.

- Scelta e supporto integrato di possibili applicazioni comuni. - Definizione realizzazione di un comune portale di accesso.

PI2S2 Dr. Giuseppe Andronico giuseppe.andronico@ct.infn.it effettivo

PI2S2 Prof. Antonella Di Stefano ad@diit.unict.it sostituto

PI2S2 Prof. Antonio Puliafito apuliafito@unime.it sostituto

SCoPE Prof. Leonardo Merola(ccordinatore)

leonardo.merola@na.infn.it effettivo

SCoPE Prof. Guido Russo guido.russo@unina.it sostituto

SCoPE Prof. Almerico Murli almerico.murli@unina.it sostituto

CRESCO Dr. Silvio Migliori migliori@enea.it effettivo

CRESCO Dr. Giovanni Bracco bracco@frascati.enea.it sostituto

CRESCO Dr. Andrea Quintiliani quintiliani@casaccia.enea.it sostituto

CYBERSAR dr Alberto Masoni alberto.masoni@ca.infn.it effettivo

CYBERSAR Dr. Daniele Mura daniele.mura@ca.infn.it sostituto

CYBERSAR Gianluigi Zanetti gianluigi.zanetti@crs4.it sostituto

ESPERTO MUR Prof. Mirco Mazzuccato mirco.mazzucato@pd.infn.it

ESPERTO MUR Prof. Francesco Beltrame francesco.beltrame@miur.it

COMITATO TECNICO SULL’INTEOPERABILITA’ (AVVISO 1575/2004)COMITATO TECNICO SULL’INTEOPERABILITA’ (AVVISO 1575/2004)

5

Riunioni del Comitato Tecnico sull’Interoperabilità:19/07/2007 27/09/2007 25/10/2007 29/11/2007 20/12/200724/01/2008

Documento sulla ConnettivitàDocumento sulla Connettività OK

Documento sull’InteroperabilitàDocumento sull’Interoperabilità OK

Documento tecnico operativoDocumento tecnico operativo in corso

Service Level AgreementService Level Agreement in corso

Prossime riunioni: 28/02/200827/03/200823/04/200822/05/2008

Documenti strategici e operativi:

6

E’ stato costituito un gruppo di lavoro tecnico operativo composto da esperti dei quattro progetti, che riferiscono al Comitato Tecnico sull’Interoperabilità (CTI).

Il gruppo tecnico operativo ha il mandato di:

elaborare un Documento Tecnico Operativo che adotti le direttive strategiche fornite dal Comitato Tecnico sull’interoperabilità;

proporre soluzioni tecniche implementative di dettaglio;

gestire tecnicamente ed operativamente l’infrastruttura comune.

7

Gruppo TECNICO OPERATIVO (AVVISO 1575/2004)Gruppo TECNICO OPERATIVO (AVVISO 1575/2004)

SCOPE (Napoli):Silvio Pardi spardi@na.infn.it (coordinatore del gruppo)Gennaro Tortone gennaro.tortone@na.infn.itFulvio Serio serio@unina.itMarco Scognamiglio marco.scognamiglio@unina.itDavide Bottalico davide.bottalico@unina.itVania Boccia vania.boccia@unina.itPI2S2 (Sicilia):Rosanna Catania Rosanna.Catania@ct.infn.itGiuseppe Platania giuseppe.platania@ct.infn.itGianni Mario Ricciardi giannimario.ricciardi@ct.infn.itGianluca Passaro gianluca.passaro@ct.infn.itAlberto Falzone alberto.falzone@nice-italy.comDaniele Zito daniele.zito@diit.unict.itEmilio Mastriani mastriani@dmi.unict.itCRESCO (ENEA):Giovanni Bracco  bracco@frascati.enea.it Carlo Scio scio@frascati.enea.itAndrea Santoro andrea.santoro@frascati.enea.it Alessio Rocchi alessio.rocchi@frascati.enea.it CYBERSAR (Sardegna):Daniele Mura daniele.mura@ca.infn.itGianmario Mereu Gianmario.mereu@ca.infn.it

8

E’ in fase avanzata di realizzazione la prima fase:

L’L’ INTEROPERABILITA’INTEROPERABILITA’ DELLE INFRASTRUTTUREDELLE INFRASTRUTTURE

Si sta avviando la seconda fase:

L’L’ INTEROPERABILITA’INTEROPERABILITA’ DELLE APPLICAZIONIDELLE APPLICAZIONI

Si è avviata la discussione sulla programmazione

2007-2013:

LA REALIZZAZIONE DELL’e-INFRASTRUTTURALA REALIZZAZIONE DELL’e-INFRASTRUTTURA

ITALIANA APERTA ALLA COLLABORAZIONE ITALIANA APERTA ALLA COLLABORAZIONE

E ALL’INTERAZIONE TRA RICERCA E IMPRESAE ALL’INTERAZIONE TRA RICERCA E IMPRESA

9

TEMPISTICATEMPISTICA

27/09/07 25/10/07

ATTIVAZIONE VO NEI SITI PROVVISTI DI SERVIZI COLLETTIVI

IMPLEMENTAZIONE DEI SERVIZI COLLETTIVI NEI SITI ANCORA SPROVVISTI

INIZIO DEL TESTBED

INTEGRAZIONE DEI 4PON

INTEGRAZIONE DEI 4PON

TESTBED SU TUTTA LA NUOVA GRIGLIA

24/01/08 28/02/0829/11/07

SPECIFICHE DEI SERVIZIDI PRIMO LIVELLO

SPECIFICHE SERVIZI DI SECONDO LIVELLO E SERVICES LEVEL AGREEMENT

20/12/07

APPLICAZIONI

COMUNI

Community web Avviso 1575: OK

12

CONNETTIVITA’ fra i progetti Avviso 1575/2004

http://www.ponricerca.miur.it/OrganizationFolders/CentriSuperC/6704.DOC

documento approvato nella riunione del CTI del 25-10-2007

13

Per la realizzazione dell’interoperabilità dell’infrastruttura Grid dei progetti dell’Avviso 1575/2004 è cruciale che la connettività (reti e comunicazioni) sia adeguata in termini di prestazioni, affidabilità, efficienza, ridondanza.

E’ essenziale il ruolo che il Consortium GARR potrà svolgere anche in futuro.

E’ indispensabile che i quattro progetti possano contare subito su interconnessioni a 622 Mb/s con una banda garantita di almeno 400 Mb/s in questa fase iniziale di interoperabilità con successivo ampliamento quando sarà realizzata l’interconnessione per tutti al Gb/s e oltre, come peraltro è già previsto nei progetti GARR di potenziamento della rete a 10 Gb/s (GARRX).

Obiettivo immediato

OTTOBRE 2007:

E’ stata inviata una lettera al MUR affinché sostenga presso il Consortium GARR la

priorità del potenziamento della CONNETTIVITA’ fra i progetti dell’Avviso 1575/2004

14

Obiettivo a medio-termine

Realizzare un anello di fibre che interconnetta i siti relativi ai progetti finanziati dal PON utilizzando WDM(Multiplazione a Divisionedi Lunghezza d’onda)con l’implementazione di collegamenti IP dedicati in tecnologia 10GigaEthernete la remotizzazione dicollegamenti fra le strutture di Storage in tecnologia FC o SCSI.

Acquisizione fibre dedicate(dark fiber) in IRU(Indefeasible Right of Use):diritto di utilizzazionepluriennale di unainfrastruttura in fibraottica già esistente

15

INTEROPERABILITA’ fra i progetti Avviso 1575/2004

http://www.ponricerca.miur.it/OrganizationFolders/CentriSuperC/6705.DOC

documento approvato nella riunione del CTI del 25-10-2007

16

L’obiettivo dell’ interoperabilità fra i progetti dell’Avviso 1575/04 è in corso di realizzazione attraverso l’adozione di uno standard comune di comunicazione e di servizi di base comuni ed è compatibile con l’interoperabilità e la facile integrazione con le altre infrastrutture di calcolo distribuito nazionali ed internazionali basate sulla tecnologia Grid.

L’interoperabilità è già stata realizzata in versione limitata e prototipale con risorse proprie dei singoli progetti già esistenti (pre-esistenze) e sarà completa entro pochi mesi e comunque entro la conclusione dei progetti.

A regime: -- potenza di calcolo di alcune migliaia di “core” per progetto-- centinaia di TB per progetto-- servizi Grid in parte centralizzati in parte replicati localmente

17

L’adozione di uno strato middleware comune (anche tramite appositi gateway) è necessario al fine di creare una comune Infrastruttura di calcolo integrata e interoperabile sia a livello italiano che europeo anche con Grid che adottano standard diversi.

Scelte strategiche:Scelte strategiche:

Standard comune di comunicazione: gLitegLite Implementazione di servizi basati su gLitegLite e LCG LCG (LHC Computing Grid) Certification AuthorityCertification Authority riconosciuta a livello mondiale

18

Servizi aggiuntivi (o di secondo livello):Servizi aggiuntivi (o di secondo livello):

Cataloghi virtuali dei file (LFC, AMGA, ecc.)Portale d’accesso (Genius, line-mode, ecc.)Monitoring (GridIce, Service Availability Montoring, ecc.)Tickets (Xoops/Xhelp, ecc.)Accounting (DGAS, APEL, ecc.)Tags (descrizione risorse, ecc.)

Service Level AgreementService Level Agreement

Servizi di base (o di primo livello):Servizi di base (o di primo livello):

Collective: VOMS VOMS (Virtual Organization Memebership Service), RB/WMS RB/WMS (Resource Broker), BDII BDII (Information Index)

Core: CE CE (Computing Element), WN WN (Worker Node), SE SE (Storage Element), UI UI (User Interface)

19

GARR

PI2S2

GARR Altri Enti e realtà

20

Servizi centralizzati e Servizi distribuitiServizi centralizzati e Servizi distribuiti

I servizi di primo livello sono replicati nelle varie sedi come stabilito nel documento di interoperabilità.

Per quanto riguarda i servizi di secondo livello tecnicamente appare opportuno centralizzare alcuni di essi per evitare eccessivo carico sulla rete Grid.

21

Applicazioni computazionali chimicheGaussian 03 (codice di riferimento per i calcoli quantistici) sfrutta l’architettura SMP, mentre AMBER e GROMACS (codici di dinamica molecolare classica) lavorano efficacemente su architettura cluster.

Applicazioni di Imaging medico (MedIGrid)1) Effettuare la ricostruzione 3D di immagini SPECT mediante l’utilizzo di una libreria di software parallelo basata su MPI.2) Effettuare denoising di sequenze ecocardiografiche mediante l’utilizzo di una libreria di software parallelo basata su PETSc.

Applicazioni di Elettromagnetismo e TelecomunicazioniPrevisione e il monitoraggio del campo elettromagnetico in centri urbani; pianificazione di reti wireless, una volta note le sorgenti di campo (antenne da installare, o già operanti, per le comunicazioni GSM), le condizioni iniziali e al contorno.

Applicazioni di Fisica subnucleare e di astrofisicaStudio delle interazioni protone-protone ad altissima energia presso l'acceleratore LHC (Large Hadron Collider) del CERN (esperimento ATLAS). Ricerca di onde gravitazionali (esperimento VIRGO). Astrofisica di Survey

Applicazioni SCoPE(prime applicazioni “esportabili” per l’inteoperabilità)

22

FLASH (www.flash.uchicago.edu) è un programma sviluppato da Alliances Center for Astrophysical Termonuclear Flashes per studiare il problema dei lampi termonucleari sulla superficie di stelle compatte, ed e’ molto usato da comunità di astrofisica. Questa applicazione richiede MPICH2.

OpenFOAM (www.opencfd.co.uk/openfoam) Open Field Operation and Manipulation, una applicazione per la simulazione di campi basata sulla risoluzione di equazioni differenziali alle derivate parziali e completamente basato sull’uso di MPICH2. Largamente usata da comunità di ingegneria e, in particolare, all’interno del progetto per calcoli di fluidodinamica che descrivono la combustione nei motori a scoppio.

Applicazioni PI2S2(prime applicazioni “esportabili” per l’interoperabilità)

23

Applicazioni CRESCO

IDL Codice commerciale con licenza non parallelo ma con un elevato numero di casi da eseguire (es. analisi immagini, analisi immagini satellitari ...). L’ENEA può mettere a disposizione attraverso il suo portale l’accesso allo sviluppo e la possibilità di eseguire fino ad 80 casi in contemporanea a livello geografico e multipiattaforma.

FLUENT Codice commerciale con licenza parallelo ad alto accoppiamento, il numero di licenze è limitato ma sufficienti ad una sperimentazione.

CPMD Codice OpenSource parallelo per la modellazione di materiali.

24

Chimica Mdynamix è un codice parallelo scalabile di simulazione di dinamiche molecolari di sistemi molecolari di varia natura.

Meteorologia MOLOCH viene utilizzato per scopi di ricerca per la simulazione, ad alta risoluzione spaziale e a breve scadenza temporale, dello sviluppo di temporali, di flussi sopra orografie complesse e di processi fisici responsabili di precipitazioni intense.

IdrologiaCODESA-3D è un modello matematico-numerico che descrive il flusso di acqua sotterranea e il trasporto di inquinanti in essa disciolti nel suolo e sottosuolo.

Astrofisicacodice per simulazioni TD-DFT di molecole in tempo e spazio reale

Ingegneria strutturale ed industrialesimulazione e modellistica nell'ingegneria di processo e della produzione e la pianifcazione territoriale ed ambientale

Fisica delle alte energieEsperimento ALICE (A Large Ion Collider Experiment) del CERN di Ginevra

Fisica della MateriaCMPTool (Caspur Model Potentials Tool), applicazione multi piattaforma sviluppata per simulazioni di dinamica molecolare

BiofisicaORAC e' un codice di dinamica molecolare classica per simulare sistemi e processi con applicazioni nel campo biologico/medico alla scala microscopica

Applicazioni CYBERSAR

25

IMPLEMENTAZIONE TECNICADELL’INTEROPERABILITA’

Documento Tecnico Operativo in corso di elaborazione

26

Documento Tecnico Operativo

SOMMARIO 1. TAG DI RUNTIME 2. JOB QUEUE 3. SERVIZI COLLECTIVE CENTRALI E DISTRIBUITI 4. SERVIZI DI MONITORAGGIO 5. ISTALLAZIONE SOFTWARE APPLICATIVO 6. INTERFACCE E PROTOCOLLI PER LO STORAGE 7. ACCOUNTING 8. GESTIONE DOWNTIME E SISTEMA DI TICKET 9. SERVICE LEVEL AGREEMENT 10. ABILITAZIONE DELLE VO COMUNI 11. INTEROPERABILITA’ CON ALTRE INFRASTRUTTURE

OK

27

TAG SPECIFICA

MIDDLEWARE

LCG-X_Y_Z Supporta versione del middleware LCG-X_Y_Z

GLITE-X_Y_Z Supporta versione del middleware GLITE-X_Y_Z

ANAGRAFICA

CITTA’ (XXXX) Città dove è situato il sito

PROJECT-NAME (XXXX) Nome del progetto

SITE-NAME (XXXX) Nome del sito

LIBRERIE E SOFTWARE

MPICH Libreria MPICH

MPICH2 Libreria MPICH versione 2

MPI_HOME_SHARED Architettura MPI con directory Shared tra i worker node

MPI_HOME_NOTSHARED Architettura MPI con directory NON Shared tra i worker node

IDL-X.Y Supporto per IDL versione X.Y

ABAQUS-X.Y Supporto per ABAQUS versione X.Y

Sono stati definiti i TAG che descrivono - secondo gli standard europei che si è deciso di adottare - le caratteristiche delle risorse hardware e software.

TAG DI RUNTIMETAG DI RUNTIME

28

Nome Coda TIPO CPUTIME (minuti) WALLTIME (minuti) PRIORITY

jobmanager-<lsf/pbs>-poncert Coda di Certificazione 2880 4320 Prioritaria

jobmanager-<lsf/pbs>-crescocert Coda di Certificazione 2880 4320 Prioritaria

jobmanager-<lsf/pbs>-cybrcert Coda di Certificazione 2880 4320 Prioritaria

jobmanager-<lsf/pbs>-pi2s2cert Coda di Certificazione 2880 4320 Prioritaria

jobmanager-<lsf/pbs>-scopecert Coda di Certificazione 2880 4320 Prioritaria

jobmanager-<lsf/pbs>-cresco_short

Coda Job Cresco 15 120 Alta

jobmanager-<lsf/pbs>-cresco_long

Coda Job Cresco 720 1440 Media

jobmanager-<lsf/pbs>-cresco_infinite

Coda Job Cresco 2880 4320 Bassa

jobmanager-<lsf/pbs>-cybr_short Coda Job Crybersar 15 120 Alta

jobmanager-<lsf/pbs>-cybr_long Coda Job Crybersar 720 1440 Media

jobmanager-<lsf/pbs>-cybr_infinite

Coda Job Crybersar 2880 4320 Bassa

jobmanager-<lsf/pbs>-pi2s2_short Coda Job PI2S2 15 120 Alta

jobmanager-<lsf/pbs>-pi2s2_long Coda Job PI2S2 720 1440 Media

jobmanager-<lsf/pbs>-pi2s2_infinite

Coda Job PI2S2 2880 4320 Bassa

Tutti i progetti implementano tre code job per ogni progetto, short, long e infinite più la coda poncert (per la certificazione dei sw) con differenti policies di CPUTIME e WALLTIME e differenti priorità.

JOB QUEUEJOB QUEUE

29

E’ stata adottata la seguente organizzazione:

Servizi distribuiti:

VOMS, BDII, RB/WMS, CE, SE, WN, UI

LFC, Ticketing

Servizi centralizzati:

Monitoring, Accounting

SERVIZI “COLLECTIVE” CENTRALI E DISTRIBUITISERVIZI “COLLECTIVE” CENTRALI E DISTRIBUITI

30

I servizi di monitoraggio sono stati implementati in maniera centrale e suddivisi tra i progetti in modo da avere molti tools attivi ma senza una eccessiva ridondanza che produrrebbe un eccessivo traffico di interrogazioni.

Web LDAP Browser (in ogni sito) GridICE (centralizzato presso SCoPE) GStat (centralizzato presso il server goc.grid.sinica.edu.tw ) SAM +VO poncert (centralizzato presso CYBERSAR) Real-Time Monitoring (centralizzato presso PI2S2)

SERVIZI DI MONITORAGGIOSERVIZI DI MONITORAGGIO

31

Monitoraggio

GSTAT

SAM – CYBERSAR https://sam-cybr.ca.infn.it/sam/sam.py

DOWN-TIME - PI2S2http://trigrid-advices.trigrid.it/support/calendar/

GRIDICE – SCoPEhttp://gridice.scope.unina.it

32

Soluzione tecnica:

Realizzare tool-kit di applicazione Pubblicare nella variabile di RUNTIME Installare il software tramite utenti SGM (Software Grid Manager )

E’ in corso la definizione delle applicazioni comuni e dei relativi tool-kit

ISTALLAZIONE SOFTWARE APPLICATIVOISTALLAZIONE SOFTWARE APPLICATIVO

33

Protocolli di trasferimentoPer mantenere il sistema di autenticazione basato sui certificati, i progetti abiliteranno il protocollo di trasferimento griftp per il trasferimento dati.

Interfacce SRM (Storage Resource Manager) e configurazioniPer garantire piena compatibilità ed interoperabilità con le altre strutture internazionali gli Storage Element impiegati per l’interoperabilità dai progetti utilizzeranno interfaccia SRM supportando srmv1.1 e srmv2.2.

Ogni progetto abiliterà sugli storage element impegnati nell’interoperabilità una quantità di spazio disco da definire creando le seguenti aree logiche:

/home/cresco, /home/cyersar, /home/pi2s2, /home/scope

INTERFACCE E PROTOCOLLI PER LO STORAGEINTERFACCE E PROTOCOLLI PER LO STORAGE

34

DGAS (Distributed Grid Accounting System )Si utilizzerà per le informazioni di accounting il sistema DGAS (ref. http://www.to.infn.it/grid/accounting/main.html) installando il sensore DGAS Gianduia sui Computing Element.

HLR (Home Location Register )Ogni sito installerà un HLR_RESOURCE ed un HLR_USER Server sul quale verranno registrate tutte le risorse disponibili per l’interoperabilità, in termini di code job.

Sarà possibile individuare un HLR di secondo livello per raccogliere le informazioni dei differenti progetti in un unico punto, utilizzando il tool grafico HLR MON.

ACCOUNTINGACCOUNTING

35

Ogni progetto utilizzerà il proprio sistema di ticketing locale.

Per la gestione dei ticket interprogetto, se un utente del progetto X riscontra problemi sul sito del progetto Y, può aprire una segnalazione direttamente sul sistema di ticketing del progetto Y.

I sistemi di ticketing devono prevedere almeno 3 aree per la suddivisione dei ticket:

SITE – per i problemi tecnici di installazione VO – per le questioni relative alla singola virtual organization, certificazioni ecc. APPLICATION – per il supporto delle applicazioni.

GESTIONE DOWNTIME E SISTEMA DI TICKETGESTIONE DOWNTIME E SISTEMA DI TICKET

36

SCOPE TICKET

TICKET PI2S2TICKET-CYBERSAR

37

E’ stato preparato un documento per definire il livello di servizi che i progetti si impegnano a garantire.

Ci si basa sull’esperienza del Regional Operation Center (ROC) italiano di EGEE.

SERVICE LEVEL AGREEMENTSERVICE LEVEL AGREEMENT

38

E’ in corso la discussionecorso la discussione dei seguenti punti principali:

DURATA DELL’AGREEMENT RESPONSABILITA’ SUPPORTO DI SECONDO LIVELLO HARDWARE E CRITERI DI CONNETTIVITA’ DESCRIZONE DEI SERVIZI MINIMI OFFERTI

(Numero di CPU e di spazio disco) SERVICE HOURS DOWNTIME SUPPORTO VO

39

Ogni sito coinvolto nell’infrastruttura interoperabile dovrà :

Fornire risorse di calcolo, storage e servizi:

numero di CPU pari al 25% delle forniture

………………………

Garantire man power sufficiente per l’interoperabilità:

almeno 2 persone, per un totale minimo di 1 FTE Gestire efficacemente le risorse del sito:

a) effettuare gli aggiornamenti relativi al software applicativo per le applicazioni di interoperabilità.

b) modificare le configurazioni coordinandosi durante le riunioni

telefoniche.

Prendere in carico e aggiornare i ticket relativi all’interoperabilità: tempo massimo di risposta: 48 ore dal lunedì al venerdì.

Memorandum of Understanding Progetti Avviso 1575Memorandum of Understanding Progetti Avviso 1575Definizione del Service Level Agreement Definizione del Service Level Agreement

per l’interoperabilità tra i quattro progetti dell’Avviso 1575per l’interoperabilità tra i quattro progetti dell’Avviso 1575(IN DISCUSSIONE)(IN DISCUSSIONE)

40

Monitorare “proattivamente” il sito, controllando periodicamente lo stato

delle risorse e dei servizi mediante tools di monitoraggio concordati:

GridICE, Gstat, SFT, ecc.

Garantire continuità al supporto ed alla gestione del sito; durante i periodi

unattended, si dovrà mettere in down-time il sito chiudendo le code.

Garantire la partecipazione dei tecnici operativi dell’ interoperabilità alle

phone conference quindicinali.

Compilare i pre-report settimanali: entro il venerdì.

Supportare le VO di test e controllo (coda poncert) con priorità maggiore

rispetto alle altre VO.

Questo MoU dovrà essere sottoscritto dal responsabile del progetto e potrà essere aggiornato in base ai feedback ottenuti durante la sperimentazione.

41

E’ attualmente in corso un’indagine per individuare aree applicative di interesse comune ai 4 progetti con l’obiettivo di creare VO tematiche trasversali.

Tali VO costituiranno un valore aggiunto per l’integrazione e la coesione tra le infrastrutture nascenti ed avranno, tra le altre attività, l’obiettivo di individuare e manutenere il software applicativo di interesse specifico.

Le soluzioni tecniche fin ora adottate sono adeguate per realizzare l’e-infrastruttura dell’Italia meridionale e per l’integrazione nell’

e-infrastruttura Grid italiana ed europea.

ABILITAZIONE DELLE VO COMUNIABILITAZIONE DELLE VO COMUNI

INTEROPERABILITA’ CON ALTRE INFRASTRUTTUREINTEROPERABILITA’ CON ALTRE INFRASTRUTTURE