EDGeS@home

Per ulteriori informazioni visitate il thread ufficiale presente nel nostro forum.

Riassunto:

Gli obiettivi del progetto sono le communità che non hanno a disposizione o accesso alle grandi potenze di calcolo nelle attuali strutture scientifiche. Al fine di supportare le esigenze di queste communità scientifiche e non, Il Consorzio interconnetterà la più grande infrastruttra di Service Grid (Griglia di Servizio) europea (EGEE) con gli attuali sistemi di Desktop Grid (Griglia Dekstop) (DG) in una forte partnership con il consorzio EGEE. I Service Grids (SG) sono molto flessibili e possono ospitare una varietà più ampia di applicazioni rispetto ai Desktop Grids, tuttavia, la loro configurazione e manuntenzione richiedono molto impegno, specialisti altamente qualificati nell'IT e risorse dedicate. D'altra parte, le Desktop Grids sono attualmente limitate solamente ad una sottoclasse di applicazioni di calcolo-intensivo ma questi sistemi facilmente scalabili (easy-to-scale) sono in grado di raccogliere 1-2 ordini di grandezza in più di potenza di calcolo utilizzando le risorse IT disponibili e volontarie coinvolte ad una frazione del costo. Creare un ponte tra questi due sistemi Grid consentirà agli utenti un'esecuzione trasparente delle applicazioni su ogni piattaforma coinvolta nella nuova infrastruttura. Prendendo i vantaggi di entrambi gli approcci, l'infrastruttura EDGES rappresenterà un passo importante verso la Grande Griglia Scientifica Europea (European wide scientific grid) dove un numero estrememamente grande di risorse potranno essere integrate a sostegno della grande sfida scientifica ed ad altre applicazioni. Il coinvolgimento dei volontari a basso costo, delle griglie desktop, nell'infrastruttura scientifica europea a griglia porterà alla creazione di un'infrastruttura sostenibile di rete europea (European Grid). Lo scopo è quello di estendere la potenziale comunità di utenti, al di là dei tradizionali scienzati e degli attuali partecipanti al calcolo volontario, per coinvolgere ulteriormente cittadini, studenti e dipendenti delle aziende dando loro la possibilità di essere coinvolti nella scienza e di applicare le tecnologie di Grid alla vita di tutti i giorni. Al fine di soddisfare questi obiettivi il progetto connetterà le Desktop Grid su base cittadina, scolastica ed aziendale con EGEE.

Obiettivi:

• identificare e coinvolgere nuove communità scientifiche che richiedano grandi quantità risorse elaborative maggiori della dimensione delle esistenti Service Grid e, inoltre, coinvolgere anche nuovi tipi di utenti e risorse oltre alle communit‡ scientifiche includendo i cittadini, gli studenti e i dipendenti delle aziende. 
• fornire interfacce e strumenti di sviluppo delle applicazioni Grid per le nuove communità scientifiche in modo da adattare le loro applicazioni all'infrastruttura EDGES.
• fornire un nuovo meccanismo di fiducia per l'infrastruttura integrata
• stabilire collaborazioni internazionali, procedure e standard per l'integrazione di Service Grids e Desktop Grids.
• contribuire alla creazione di un'infrastruttura Grid sostenibile in Europa attraverso l'integrazione dei Service Grid e dei Desktop Grid nazionali ed internazionali.

Piano di lavoro

Il consorzio creerà le infrastrutture integrate in due fasi. La fase 1 sarà quella di creare un ponte che permette ai progetti Desktop Grid di spedire lavoro ad ogni Organizzazione Virtuale di EGEE che sarà pronta a sostenere questi progetti esterni. La fase 2 creerà il ponte in direzione opposta estendendo EGEE con la capacità dei Desktop Grids connessi, permettendo alle loro communità di utilizzare in modo trasparente queste nuove risorse. Durante questa fase il consorzio former‡ sia delle communità su come si utilizza l'infrastruttura integrata, le supporterà e svilupperà le loro applicazioni per Desktop Grid in grado di funzionare sulla nuova infrastruttura.

Attività di networking: progetto amministrativo e gestione tecnica prevedono il coordinamento del consorzio mettendo in atto una struttura di gestione, decisione e meccanismi di comunicazione che consentono l'effettiva amministrazione e gestione tecnica del progetto. I Servizi di conoscenza (diffusione, formazione e consulenza) si concentrano sulla fornitura di consulenti esperti e supporto tecnico alle nuove communità nell'adozione e personalizzazione dei servizi di EDGeS. Dissemineranno la conoscenza prodotta dal progetto attraverso l'organizzazione di eventi focalizzati e formeranno scienzati per sviluppare le applicazioni per l'infrastruttura gestita dal consorzio. Questa attività identifica nuove communità che necessitano dell'infrastruttura integrata e organizza un loro forum utenti. Essa stabilisce, inoltre, un forum per le industrie per attrare compagnie che sono disposte a connettere i loro Desktop Grid locali basati su reti aziendali nell'infrastruttura EDGeS. La Standardizzazione delle procedure si concentra sullo sviluppo di nuovi standard per la generica integrazione di Service Grids e Desktop Grids.

Attività di servizio: combinare il servizio di gestione EGEE-DG è un'attività per stabilire e mantenere un infrastruttura integrata, una produzione di servizi che combinano EGEE e gli esistenti sistemi di Desktop Grids locali e pubblici. La gestione dei servizi di supporto dell'infrastruttura fornisce un'applicazione di test, un'infrastruttura di validazione, procedure di analisi e validazione come servizi per le varie communità. Sarà anche stabilito e mantenuto un corso di formazione e sviluppo dell'infrastruttura applicativa. Il Servizio di supporto alle applicazioni supporta le attuali e future communità nello sviluppo delle loro applicazioni per l'infrastruttura integrata. Stabilirà due centri di sviluppo di applicazioni dove gli utenti saranno forniti di aiuto diretto nel "grigliamento" delle loro applicazioni e/o rendendole compatibili nel desktop grid.

Attività comuni di ricerca: SG-DG Bridges Technologies (Tecnologie ponte SG-DG) sviluppa l'integrazione dei Service Grids e dei Desktop Grids mascherando le diverse tecnologie a livello utente. Questa attività di ricerca include affrontare i problemi di task scheduling (compito di programmazione) attraverso le diverse piattaforme e risolvere i problemi di sicurezza. SG-DG Support Technologies (Tecnologie di supporto SG-DG)  produce strumenti ed interfacce di programmazione attraverso i quali gli utenti possono adattare le loro applicazioni all'infrastruttura integrata. Inoltre forniscono monitoraggio e strumenti di benchmark a sostegno dell'interazione di entrambi gli ambienti e valutazione dell'operazione di bridge (ponte). SG-DG Data Access (Accesso ai dati SG-DG) si concentra sull'estensione delle capacità del nuovo ponte per fornire meccanismi di trasferimento di insiemi di grandi dati. Estenderà ed integrerà l'attuale tecnologia di distribuzione Peer-to-Peer per adattarla alle sfide dell'ambiente di un Desktop Grid, costruendo una sicura ed affidabile rete che impone l'integrità dei dati. Questa attività consentirà anche alle attuali applicazioni Desktop Grid di accedere alla rete di distribuzione dei dati.

Communità utenti: il consozio fornirà l'infrastruttura integrata EGEE-DG come servizio per le communità già selezionate che richiedono molta potenza di calcolo nei campi della scoperta di farmaci, ingegneria, algoritmi combinatori di asta, applicazioni sulla fusione nucleare, algoritmi bio-ispirati, sistemi mobili, e-business, il profilo di identificazione a raggi X, simulazione della dinamica dei dispositivi laser, recupero audio distribuito, rendering 3D e altro. Il progetto stabilirà un forum utente ed un forum industria al fine di identificare e supportare molte communità che hanno bisogno dell'infrastruttura integrata che estenderà l'infrastruttura EGEE con più di 100.000 pc di diversi Desktop Grids.

Aspetti internazionali: EDGeS è pronto per supportare ogni communità internazionale che richiedano potenza di calcolo superiori alle esistenti Service Grid. I progetti intendono collaborare, con forza, con ogni grid internazionale e progetti che richiedono grande potenzadi elaborazione e, quindi, sono interessati ad integrare il loro Service Grid con i Desktop Grids, o nell'integrazione del loro Desktop Grid con i Service Grids. I partner parteciperanno attivamente al lavoro del forum Open Grid al fine di sviluppare e promuovore standard di interoperabilità ed integrazione di service grids e desktop grids.

Un grande numero di applicazioni sono state portate nella infrastruttura grid di EDGeS.

Qui sotto troverete la lista completa:

• DASP (elaborazione del segnale)
• ISDEP (ricerca sulla fusione nucleare)
• ViSAGE (analisi video)
• EMMIL (simulazione di e-Market)
• MOPAC (Pacchetto degli orbitali molecolari)
• pLINK (analisi dati dei fenotipi/genotipi)
• SLinCA (LEggi di scala nelle aggregazioni di gruppi)
• AutoDock (Simulazioni di docking molecolare)
• Blender (Rendering Video 3D)
• Patient Readmission Application (Richiesta di riammisione del paziente)
• X-ray (Ottimizzazione diffrazione profili raggi-X)
• VisIVO (Visualizzazione interfaccia per l'Osservatorio Virtuale)

L'elaborazione numerica del segnale senza alias (DASP) Ë un insieme di metodologie che utilizzano campionamenti non uniformi e algortimi specializzati nell'elaborazione numerica dei segnali che permettono l'elaborazione di segnali senza la conoscenza del supporto spettrale nelle gamme di frequenza che sono di larghezza superiore alla metà della frequenza di campionamento media. L'applicazione di grid computing permette ai ricercatori di quest'area di progettare ed analizzare sequenze di campionamento non-uniformi più efficientemente di quanto non fosse possibile in precedenza. 

Sfida

Nella tradizionale elaborazione numerica dei segnali (DSP) i segnali sono campionati ad intervalli temporali uniformemente distribuiti. Mentre questi sistemi di campionamento hanno evidenti vantaggi, come facilitare l'uso di algoritmi di elaborazione efficienti (es. trasformata veloce di Fourier (FFT)), ma soffrono di una ben nota limitazione che impedisce il loro utilizzo in gamme di frequenza più ampie della metà della velocità di campionamento. Questa limitazione, conosciuta come aliasing, non permette di differenziare le componenti sinusoidali dei segnali se la somma o differenza delle loro frequenze è un multiplo intero della frequenza di campionamento.

L'elaborazione numerica del segnale senza alias (DASP) Ë un approccio che offre effettive soluzioni nell'elaborazione dei segnali con una stima conservativa del supporto spettrale. È utilizzato attentamente nella progettazione di sistemi di campionamento non-uniformi low-rate e in algoritmi di elaborazione più adeguati. Soluzioni di tipo DASP si basano su campionamenti casuali oppure su campionamenti non uniformi. Comunque, la selezione dell'ottimale sequenza di campionamento è un problema di elaborazione costoso e le soluzioni basate su un singolo computer potrebbero richiedere lunghi tempi di attesa prima dei risultati. La possibile miglior sequenza di campionamento può essere selezionata attraverso la generazione di tutte le possibile sequenze di campionamento e poi calcolare un valore, per ognuna di queste sequenze, che descrive la loro efficienza. Questo significa trovare tutte le soluzioni di un'equazione lineare e poi, per ognuna di quelle soluzioni, generare tutte le possibili permutazioni degli intervalli di campionamento. Per i tipici problemi il numero di soluzioni possono essere di poche centinaia generando circa 109 permutazioni. Calcolare il rendimento per ognuna di queste permutazioni può richiedere settimane su un computer indipendente.

Sinistra: Sinusoidi a 160MHz e 40MHz entrambe adatte alla misura del segnale a 200MSps.

Destra: La sinusoide a 160MHz si adatta molto meglio al campionamento non uniforme rispetto a quella a 40MHz.

Utenti

Gli utenti primari dell'applicazione sono i ricercatori del Gruppo di Ricerca del Centro di Analisi del Sistema dell'Università di Westminster (Center for System Analysis Research Group). Il gruppo è stato finanziato da diversi progetti europei ed inglesi ed una delle principali aree di ricerca  dell'elaborazione numerica dei segnali senza alias.
Sito: http://www.westminster.ac.uk/schools/computing/research/electronic-and-communication-engineering/centre-for-systems-analysis.

Soluzione

L'applicazione originale è stata scritta come un codice sequenziale e ha elaborato per settimane su un singolo computer per problemi di media dimensione. L'algoritmo è stato parallelizzato e portato su entrambe le piattaforme Service e Desktop Grid all'interno del progetto europeo EDGeS. Dopo aver trovato tutte le soluzioni per l'equazione lineare, diversi computer del Grid possono lavorare su differenti sottoinsiemi di queste soluzioni generando tutte le permutazioni degli intervalli e trovando la soluzione ottimale dentro al specifico sottoinsieme. La soluzione migliore di tutte può essere dunque trovata come il minimo dei valori calcolati all'interno dei sottoinsiemi.
L'applicazione può essere eseguita su una piattaforma Desktop Grid basata su entrambe le tecnologie BOINC o XtremWeb. L'applicazione è, inoltre, in grado di girare sistemi Service Grid ed è stata utilizzata con successo sulla EGEE Grid e la UK National Grid Service. Come risultato del progetto, gli utenti possono ora sfruttare entrambi i tipi di risorse senza soluzione di continuità e, in modo più appropriato, far girare esperimenti su una più ampia scala rispetto a quanto era possibile precedentemente. Il portale P-GRADE Grid fornisce una conveniente interfaccia utente per l'applicazione e permette ai ricercatori di eseguire le applicazioni senza rendersi conto dei dettagli di basso livello dell'utilizzo dell'infrastruttura Grid.

 Parallelizzazione dell'algortitmo DSP

Risultati

Utilizzando l'infrastruttura EDGeS tipici problemi su larga scala possono essere risolti, approssimativamente, 50 volte più velocemente rispetto ad una singola macchina. Ciò ha portato successo negli esperimenti su dati di input che non avevano potuto testare precedentemente. Per esempio, un campionamento che sull'infrastruttura Grid ci impiega meno di 18 ore, vuol dire che su una macchina singola avrebbe impiegato più di un mese. I risultati consentono agli scienzati di eseguire un maggior numero di simulazioni e su una più ampia scala rispetto a quanto era possibile precedentemente. La conveniente interfaccia del portale Grid consente anche loro di iniziare e monitorare gli esperimenti da remoto attraverso un browser internet.

Flusso di lavoro che esegue l'applicazione DSP sull'infrastruttura EDGeS. Il flusso di lavoro è accessibile dal portale P-GRADE.

 Esecuzione dell'applicazione DASP sull'infrastruttura EDGeS da dentro il portale P-GRADE

Le attivit‡ risultanti sul Desktop Grid Westminster

Ambiente

L'EDGeS Application Development Method (EADM) è un metodo che standardizza il porting delle applicazioni ad un complesso ambiente Grid. Il metodo assicura che è il miglior percorso possibile da scegliere per il porting.

La metodologia EDGes Application Development utilizzata nel porting dell'applicazione al Grid.

Il progetto EDGeS mantiene una infrastruttura Grid che connette Desktop Grid e Service Grid.

L'infrastruttura Grid di EDGeS.

Produrre energia in modo sicuro e compatibile con l'ambiente è una delle maggiori sfide dei nostri giorni. La fusione nucleare è una delle sfide più promettenti, ma è difficile da padroneggiare con le tecnologie attuali. Si potrebbe fornire energia senza fine (stimata per durare circa 2 milioni di anni, senza produrre CO₂ e rifiuti nucleari). I reattori per la fusione nucleare sono intrisecamente sicuri perché si fermano automaticamente quando qualcosa va storto. Attualmente l'Europa, ed altri paesi di tutto il mondo, stanno lavorando insieme per costruire un reattore a fusione nucleare chiamato ITER. Per prevedere ed ottimizzare il comportamento di ITER, sono necessari molti computer per i calcoli. Il National Fusion Laboratory del CIEMAT in Spagna sta sviluppando il codice ISDEP che prenderà parte a queste simulazioni. Questo è stato portato, dal progetto EDGeS, sulla propria infrastruttura ed è utilizzato in EDGeS@home.

SFIDA

Questo progetto è stato sviluppato nell'ambito di un progetto a lungo termine per sviluppare un metodo cinetico per lo studio del trasporto del plasma confinato magneticamente. Questi sistemi hanno ricevuto parecchie attenzioni scientifiche negli ultimi decenni, dato che la fusione è destinata a diventare una via commercialmente fattibile a basso costo, virtualmente inesauribile, distribuile in tutto il mondo e ambientalmente accettabile.
Lo scopo principale del programma sulla termofusione nucleare controllata è di confinare un plasma sufficientemente caldo, di sufficiente alta densità e per abbastanza tempo. Soddisfando questi requisiti, la seguente reazione di fusione nucleare può prendere vita in modo sostenibile.

Il processo di fusione nucleare. In questa reazione, due nuclei leggeri (deuterio e trizio) collidono e formano un nucleo pesante (elio) ed un neutrone. A causa della differenza di massa tra reagenti e prodotti e data la conosciuta relazione E=MC², il neutrone è generato con un'altissima energia cinetica. Questo neutrone energetico può essere utilizzato (indirettamente) per scaldare l'acqua o qualsiasi altro fluido e, dal quel momento in poi, utilizzare l'energia.

La materia all'interno di un reattore a fusione è in uno stato di plasma: quasi tutte le particelle sono ionizzate e quindi il sistema si basa sull'interazione di cariche libere su una lunga gamma di forze elettromagnetiche. La forte risposta ai campi elettromagnetici delle cariche positive e negative rende le proprietà del plasma molto diverse da quelle dei solidi, liquidi o gas. Quindi il plasma è considerato un diverso stato della materia.

Un immagine di un impianto di fusione nucleare

Al fine di adempiere alle temperature e densità richieste, è obbligatorio confinare il plasma. L'idea di base è che il movimento medio di una particella carica segua la direzione delle linee del campo magnetico (i movimenti nel piano perpendicolare al campo magnetico si chiamano rotazioni di Larmor). Ci sono due principali tipi di dispositivi per confinare il plasma: il tokamak e il stellarator. Tuttavia, in un dispositivo a confinamento magnetico, parecchi effetti principali possono aggiungersi rispetto al caso di un campo magnetico uniforme:

• il campo magnetico non può essere omogeneo dato che una configurazione a campo magnetico toroidale ha, dalla costruzione, una curvatura magnetica e, grazie al numero finito di bobine, il campo magnetico presenta delle ondulazioni lungo le linee di campo. 
• Nella simulazione circa 10²³ particelle possono esser confinate e interagiscono tra loro attraverso le collisioni particella-particella.

Questi principali effetti risultanti sono chiamati trasporti collisionali che fa si che le particelle e il calore siano persi dalla regione di core del reattore verso il bordo. Questo meccanismo deve quindi essere conosciuto e controllato per una buona prestazione dei futuri reattori ed è lo scopo del lavoro del National Fusion Laboratory.
Il National Fusion Laboratory ha sviluppato il codice ISDEP (Integrator of Stochastic Differential Equations for Plasma - Integratore di Equazioni Differenziali Stocastiche per il Plasma) che cerca di superare alcune delle limitazioni degli approcci standard per la risoluzione del trasporto collisionale. Partendo dai primi principi, sono arrivati alle equazioni stocastiche differenziali (SDE) che possono essere calcolate in un'infrastruttura di calcolo distribuito o in un Grid: ogni computer calcola una (o più) traiettorie di uno ione nel plasma.
I dati di tutte le traiettorie sono raccolti e trattati statisticamente. Questo ci permette di osservare alcune caratteristiche globali del trasporto che non sono presenti nei consueti modelli neoclassici: monotona crescita di calore e flussi di particelle con minore raggio, trasporto non diffusivo, assimetrie sulle superfici magnetiche e distribuzione delle funzioni non-Maxwelliane.

Una sezione centrale di un dispositivo plasma, il stellarator TJ-II.Le proprietà di trasporto del plasma sono calcolate utilizzando il codice ISDEP.

Soluzione

Il codice ISDEP Ë stato progettato fin dall'inizio per scalare perfettamente nelle piattaforme di calcolo distribuito, come GRID o calcolo volontario. Non c'è bisgno di comunicazione tra i nodi. Una tipica simulazione consiste nel lanciare molti lavori che sono identici in tutto ma in modo casuale. Quindi tutto l'output è raccolto, analizzato di seguito e si ottengono le quantità fisiche. Quindi il flusso di lavoro è piuttosto semplice.

Risultati

L'efficienza del codice in un Grid Ë vicina al 100% dato che tutte le esecuzioni sono indipendenti. Una simulazione che fornisce risultati rilevanti può richiedere circa 10-15 anni di tempo di CPU in un Grid. Le analisi di questi risultati possono essere fatte su macchine locali e non richiedono molto tempo: all'incirca un'ora di computazione.
Il porting di ISDEP nel Grid è stato abbastanza veloce e facile. Abbiamo scritto un file Job Description Language (JDL - Linguaggio di Descrizione Lavoro) per un lavoro parametrico ed uno script per eseguire il codice nei nodi lavoratori. Tipicamente un grosso file è replicato nelle unità di memorizzazione e copiato nei nodi lavoratori prima dell'esecuzione. Sono necessari anche alcuni file di piccole dimensioni ma questi sono spediti insieme all'eseguibile.

Traiettorie delle particelle (in verde) calcolate con ISDEP nel campo magnetico delle bobine del dispositivo TJ-II.

Con una conoscenza base del linguaggio JDL, Unix Shell/Python e del middleware GLite, ISDEP fu portato al Grid in un giorno.

Background

Gli sviluppi di ISDEP sono parte di una collaborazione a lungo termine per stimare il trasporto dai principi base ad un dispositivo complesso di confinamento magnetico 3D. L'idea è quella di incorporare sempre più fenomeni fisici che possono essere calcolati con il calcolo distribuito. Quindi, oltre le collisioni e le reali strutture dei campi magnetico ed elettrico, è possibile introdurre termini come interazione onda-particella e parecchie risonanze tra particella e instabilità del plasma.
Questo codice è stato sviluppato in una collaborazione tra l'Istituto di Biocomputazione e Fisica dei sistemi dell'Università di Saragozza (Institute of Biocomputation and Physics System BIFI) ed il Laboratorio di Fusione Nazionale (National Fusion Laboratory), Centro Ricerche Energetico, Ambientale e Tecnologico (Centre of Energetic, Environmental e Technological Research), in collaborazione con la Università Complutense di Madrid. L'applicazione è di interesse scientifico per i ricercatori di queste tre istituzioni.

La piattaforma ViSAGE rappresenta un cambiamento di paradigma ed un allontanamento dalla convenzionale visione di applicazione e programmi di video monitoring, muovendosi verso un mondo in cui il video monitoring è fornito come un utile servizio. Questo cambiamento di paradigma permetterà agli utenti finali (siano essi famiglie o piccole aziende) di utilizzare il video monitoring in modo economico, affidabile e facilmente disponibile, oltre ad accedere alle funzionalità di analisi, formalmente solo disponibili ad esperti utenti finali.

Sfida

L'applicazione ViSAGE Ë caratterizzata in natura semi real-time, dove il processo degli eventi è completato in pochi minuti dall'avento attuale. In aggiunta, l'applicazione è caratterizzata da una forte correlazione di eventi successivi.
Forte correlazione tra eventi successivi

L'architettura della piattaforma ViSAGE include, dal lato utente, un indirizzo IP di una telecamera (preferibilmente wireless) connessa ad internet e, dal lato provider, di un server video che immagazzina i video (ricevuti via WAN) ed ogni meta dato che lo descrive, che sono il risultato del servizio di analisi video eseguito. L'analisi video può essere eseguita localmente su computer dedicati, al fine di consentire l'analisi di grandi quantità di informazioni video; la piattaforma permette l'utilizzo di risorse computazionali remote utilizzando l'utility di elaborazione.

Utenti

ViSAGE è utilizzato come una parte della piattaforma Correlation Systems "INSider", una piattaforma geospaziale per il rilevamento e la prima rilevazione di pericoli interni ad un'organizzazione.

Soluzione

ViSAGE raggiunge questi obiettivi attraverso l'utilizzo di reti di Grid Computing che danno due vantaggi:

• elaborazione distribuita
• elaborazione parallela

In questo modo il video ha solo bisogno di essere catturato fisicamente nella locazione dell'utente finale. Tutti i processi possono essere fatti a distanza su un'entità più specializzata e potente.

In giallo le caratteristiche rilevate automaticamente

Risultati

• sulla piattaforma BOINC, il tempo di elaborazione di uno streaming video per raggiungere il limite teorico di tempo di trasferimento rete + tempo di elaborazione è di solo un paio di immagini
• l'elaborazione generale è una diretta funzione del numero di processori

Background

Ambiente

L'EDGeS Application Development Method (EADM) è un metodo che standardizza il porting delle applicazioni ad un complesso ambiente Grid. Il metodo assicura che è il miglior percorso possibile da scegliere per il porting.

La metodologia EDGes Application Development utilizzata nel porting dell'applicazione al Grid.

Il progetto EDGeS mantiene una infrastruttura Grid che connette Desktop Grid e Service Grid.

L'infrastruttura Grid di EDGeS.

Correlation Systems

Correlation Systems Ltd. è un'azienda di ricerca e sviluppo con base in Israele. Fin dalla sua fondazione nel 1992, Correlation Systems ha basato il proprio lavoro di ricerca e sviluppo sui seguenti campi tecnologici complementari: analisi del comportamento, Data Mining Geografico, fusione dati, posizionamento e tracciamento, elaborazione Grid. Questi sono stati applicati in una vasta gamma di campi, incluso: ottimizzazione dei servizi di trasporto e trasporto pubblico, sicurezza perimetrale (analisi dei dati di accesso), industria della pesca, rilevazione frode ed una gamma di altri sistemi che implementano le metodologie C4iSTAR.
Sito web: http://correlation-systems.com/.

L'E-commerce tra aziende ha sempre più un ruolo importante nella Supply Chain Management (SCM - gestione della catena di fornitura) facilitando l'integrazione e riducendo i costi. L'e-market può essere un'importante catena in questi processi. Uno dei simulatori di e-Market è EMMIL. EMMIL facilita le negoziazioni tre lati tra compratori, rivenditori e fornitori di logistica di terza parte al fine di ottimizzare i costi totali che non potevano essere offerti prima. Questo è un lavoro ad elaborazione intensiva che beneficia del l'elaborazione Grid.

Sfida

EMMIL facilita le negoziazione 3-parti tra compratori, rivenditori e fornitori di logistica al fine di ottimizzare i costi totali che non potevano essere offerti prima.  

Anche se ci sono certi standard commerciali di e-marketplace, i ricercatori sono alla ricerca di nuovi modelli al fine di migliorare l'efficienza della catena di fornitura. La ragione della mancanza di integrazione nelle attuali pratiche può essere l'algoritmica e la complessità di elaborazione che coinvolge il meccanismo di negoziazione tre parti. Diffondere il modello aiuterà ad ottmizzare le logistiche al fine di ridurre sprechi di energia, consumo di risorse naturali e ridurre l'inquinamento ambientale.
Matematicamente il problema principale è impostare il problema lineare. Per essere precisi è quello di risolvere la seguente equazione:

dove:
N - numero di oggetti (prodotti) da acquistare;
M - numero di fornitori
L - numero di terze parti logistiche
Qik - quantità di prodotti acquistati i. dai venditori k;
Pik - Prezzo unitario del prodotto i. dal venditore k;
Fkl - fissare i costi di consegna e camion dei beni dal venditore;
Vkl - Costi variabili di consegna dei beni dal venditore k. (costo per unità caricata);
Z - dimensione standard del camion;
xjl E {0,1} - variabile di decisione;
xjl = 1 - offerta j. di terze parti logistiche I. Ë selezionato come vincitore.

La complessità dell'algoritmo d'asta e la composita struttura d'offerta rendono difficile l'ottimizzazione. La soluzione che conosciamo oggi richiede una lunga elaborazione che può richiedere diverse ore di esecuzione su un singolo computer ed ecco perché è necessaria l'infrastruttura Grid.

Utenti

Il concetto ed il progetto del marketplace EMMIL è nato nella Scuola Internazionale di Business di Budapest (International Business School (IBS)) ed il primo prototipo fu sviluppato insieme da IBS e SZTAKI. Da quando gli argomenti e-Marketplace e SCM sono coperti dai programmi di studio di IBS ed EMMIL è utilizzato dai loro insegnanti, gli studenti della IBS conoscono EMMIL come una soluzione per il problema della negoziazione delle tre parti tra compratori, venditori e fornitori di logistica. Attualmente gli utenti sono principalmente insegnanti ma prossimamente gli studenti, dopo la laurea, saranno potenziali utenti di EMMIL mentre diffonderanno queste conoscenze alle loro aziende. Inoltre, il prototipo di mercato EMMIL sarà offerto gratuitamente alle aziende, per un utilizzo di prova, durante l'introduzione dei vantaggi implementati con EMMIL. Il modello ed il prototipo sono stati pubblicati su riviste e conferenze dove scienzati hanno mostrato interesse nel nuovo modello e prototipo.

Il flusso di lavoro di EMMIL

Soluzione

L'applicazione EMMIL è stata portato in EGEE come uno Studio di Parametri di un Flusso di lavoro sviluppato con il portale P-Grade 2.7. La paralellizzazione è stata implementata utilizzando un Generator job nel flusso di lavoro che genera gli input per il programma principale che esegue i calcoli. Quando tutte le istanze del programma principale finiscono, un Collector Job raccoglie i risultati del programma principale e crea il risultato finale. Tutto il flusso di lavoro genera una parallelizzazione dei dati.
Solo l'applicazione core è stata portata in BOINC, le altre due (Generator, Collector) girano su EGEE come erano prima del porting. Le connessioni tra l'applicazione core e le altre due è realizzata, da EGEE, dal bridge Desktop Grid sviluppato nel progetto EDGeS.
Grazie ad una utility di wrapper di nuova generazione chiamata GenWrapper, permette al programma core di EMMIL di girare sui Desktop Grid facilmente. GenWrapper è un'utilità di aiuto, per fare il porting, che permette alle applicazioni ereditarie di girare sulle Desktop Grid senza nessuna modifica. La seconda parte del lavoro di porting è stata quella di sviluppare un validatore. In BOINC l'applicazione validatore è raccomandata per la validazione dei risultati prodotti con diversi client dagli stessi input. Compara i risultati ridondanti e decide quali sono da considerare corretti. Ci sono già alcuni validatori pre-sviluppati in BOINC a questo scopo; tuttavia nessuno di questi era appropriato dato che i file dei risultati possono variare su differenti sistemi operativi, come nel caso di EMMIL. Questo era dovuto alla differenza di rappresentazione e manipolazione dei numeri reali tra Windows e Linux. EMMIL utilizza i calcoli reali in modo intensivo cosÏ che un nuovo validatore è stato sviluppato, durante il porting, per gestire questo caso.

Risultati

Il principale risultato del porting dell'applicazione EMMIL è quello di eseguire il flusso di lavoro molto più velocemente dovuto all'utilizzazione delle risorse di BOINC. Poiché la parte che richiede più tempo può essere programmata da BOINC d'ora in poi e dato che i progetti BOINC solitamente forniscono una grande quantità di risorse di quelli basati su gLite, il progresso sarà più veloce rispetto a prima grazie all'infrastruttura EDGeS. Il tempo speso per permettere al programma di girare su BOINC era stato di solo alcuni giorni grazie all'utility wrapper chiamata GenWrapper.

Il portale EMMIL, form di spedizione Auction

Background

EMMIL è stato portato dalla Scuola Internazionale di Business (International Business School - IBS (Ungheria)), Laboratorio si Sistemi Paralleli e Distribuiti (Laboratory of Paralel and Distributed Systems - MTA SZTAKI (Ungheria)).

Il progetto EDGeS mantiene una infrastruttura Grid che connette Desktop Grid e Service Grid.

L'infrastruttura Grid di EDGeS.

MOPAC (Molecular Orbital PACkage, Pacchetto Orbitali Molecolari) è un pacchetto software di chimica quantistica semi empirica per la predizione delle proprietà chimiche e modellazione delle reazioni chimiche. È utilizzato da chimici e biochimici sia per la ricerca, sia per l'insegnamento e gira sulle piattaforme Windows e Linux.

Sfida

Il programma originale è un software di pubblico dominio scritto in Fortran. Lo scopo principale in EDGeS era quello di consentire l'esecuzione del lavoro di MOPAC sia su un BOINC Desktop Grid sia su EGEE nello stesso momento con il portale gUSE/WS-PGRADE. In base al risultato, le risorse per eseguire MOPAC aumenteranno e con questo il tempo di esecuzione del calcolo del flusso di lavoro decrementerà.

Utenti

Gli utenti primari, del incrementato flusso di lavoro (Descriptor Calculation) con il portale e sistema CancerGrid, sono i membri del consorzio. Il consorzio CancerGrid consiste di parecchie università, istituti di ricerca e SMEs (Piccole e medie imprese). Il progetto, nel suo piano di esplorazione, dichiara di tentare di creare una versione a livello prodotto del sistema CancerGrid. Una volta realizzato questo piano, sarà disponibile per tutte le persone che lavorano nella chimica.

Soluzione

Il più complicato e computazionalemten intenso flusso di lavoro è il calcolo dei descrittori. La struttura del flusso di lavoro per il calcolo dei descrittori potete vederlo nella seguente figura.

Flusso di lavoro per il calcolo dei descrittori nel CancerGrid

Hanno scelto di fare il porting dello strumento MOPAC sia per EGEE che per BOINC per le seguenti ragioni: viene eseguito un maggior numero di volte, il suo tempo di esecuzione Ë il pi˘ grande tra gli strumenti nel flusso di lavoro, il software Ë di pubblico dominio cosÏ da non causare problemi di licenza per l'esecuzione su EGEE.
Il porting sull'infrastruttura EGEE è stata fatta con l'aiuto del portale WS-PGRADE/gUSE. Il binario su Linux è compilato con gLite cosÏ l'applicazione può essere eseguita senza modifiche. Quello che hanno fatto è quello di sviluppare un'estensione UniBroker del portale Ws-PGRADE/gUSE in modo che l'applicazione Mopac possa essere eseguita sia su EGEE sia su Desktop Grid in modo misto. L'estensione UniBroker del portale è in grado di spedire lavori a differenti tipi di risorse nelle stesso momento. Nei loro test, hanno eseguito un flusso di lavoro biochimico generando migliaia di lavori per Mopac che sono stati processati con BOINC e precedentemente configurati con GILDA VO. Il componente UniBroker ha presentato un certo numero di lavori Mopac a GILDA ma la maggior parte dei lavori sono andati a BOINC dato che forniva molta più potenza computazionale.
La soluzione implementata è stata testata con successo sul portale CancerGrid dove un desktopgrid BOINC basato su 3GBridge e su un pacchetto SZTAKI Local Desktop Grid sono stati installati e il GILDA VO è stato configurato. Le istanze di lavoro del flusso di lavoro di MOPAC sono state trattate su entrambi i tipi di gird mentre altri erano solo su BOINC o localmente.

Il form utente di MOPAC

Risultati
Da quanto il flusso di lavoro del Descriptor Calculation e MOPAC sono utilizzati con i dati in maniera parallela, l'incremento di velocità è solamente rilevata quando i tipi di risorse grid EGEE e BOINC possono essere utillizate durante l'esecuzione del flusso di lavoro. Quindi, il principale obiettivo del porting era quello di permettere questa modalità di esecuzione nel calcolo dei descrittori.
Il risultato, il portale WS-PGRADE/gUSE con il componente UniBroker e l'applicazione Mopac, è stato dimostrato con successo durante la conferenza EGEE'08 alla fine di settembre 2008 ad Istanbul e al SuperComputing 2008 exbihition ad Austin, Texas, USA.
L'attività di porting è stata eseguita dal Laboratorio si Sistemi Distribuiti e Parallelizzati - MTA SZTAKI (Ungheria)

Background

Nei 3 anni del progetto di ricerca europeo multidisciplinare CancerGrid, gli 11 membri, il consorzio SME-led prevede di sviluppare e rifinire metodi per l'arrichimento delle librerie molecolari per facilitare la scoperta di potenziali agenti anti-cancerogeni. Utilizzando la tecnologia computer grid assistita, la probabilità di trovare un anticancerogeno porta ad aumentare considerevolmente la traduzione delle conoscenze di base allo stadio applicativo.
Le mire del progetto CancerGrid sono di sviluppare librerie molecolari focalizzate con un alto contenuto di anti-cancerogeni che portano e costruiscono modelli per la predizione delle varie proprietà delle molecole. L'elaborazione delle molecole è automatizzata con diversi algoritmi. Questi algoritmi possono essere eseguiti in uno stretto ordine per produrre l'output desiderato, tuttavia i flussi di lavoro sono stati progettati per entrambe le procedure come calcolo dei descrittori, costruzione modello e predizione proprietà.
WS-PGRADE/gUSE homepage: http://www.guse.hu
MOPAC homepage: http://openmopac.net
Homepage progetto CancerGrid: http://www.cancergrid.eu

Il progetto EDGeS mantiene una infrastruttura Grid che connette Desktop Grid e Service Grid.

L'infrastruttura Grid di EDGeS.

PLINK è un'applicazione per l'analisi dei dati di genotipo/fenotipo. Si focalizza sull'analisi della genotipizazzione di massa e così non ha il supporto per i passi precedenti l'ottenimento dei dati dalle attrezzature di laboratorio. Inoltre non supporta le fasi successive come visualizzazione o grafica sebbene sia integrato con altri strumenti come Haploview o il pacchetto statistico R. L'applicazione è in grado di eseguire diversi tipi di analisi che sono utili in una vasta gamma di campi della ricerca biomedica. Un tipico utilizzo comprende diverse esecuzioni di linee di comando con diverse serie di differenti parametri.

Sfida

CIC biogune utilizza PLINK per eseguire molti diversi tipi di analisi massice. La sua capacità di eseguire test di associazioni ed altri tipi di analisi utilizzando l'applicazione all'interno di un prezioso strumento per la ricerca su malattie ereditarie. La principale sfida per il CIC bioGUNE è quello di incrementare, con l'incremento della potenza di elaborazione di cui hanno bisogno, l'analisi delle grandi quantità di dati entro un tempo ed un costo accettabile. Lo scopo del porting ad EDGeS è migliorare la scalabilità e l'ottimizzazione dei loro sistemi IT.
L'applicazione può girare solamente da linea di comando. Esiste un'applicazione grafica (gPlink) che esegue l'applicazione da riga di comando ma solo con un limitato numero di analisi disponibili e può gestire solo una parte dei parametri esistenti, che nel caso tipico dell'attuale linea di comando sono eseguiti, devono essere rivisti e modificati. L'input e l'output sono dei file di testo i cui formati sono considerati standard nella communità scientifica. Per incrementare la velocità e ridurre la memoria, PLINK è in grado di utilizzare formati binari specifici. L'input per la fase di analisi è utilizzato anche in altri strumenti (come Haploview per la visualizzazione) quindi questo file intermedio deve essere, inoltre, incluso nel set di file di output.
L'applicazione ha una portata molto vasta ed è utile in diversi campi di ricerca. Dalla lunga lista delle analisi disponibili, quelle che i nostri utenti utilizzano più frequentemente sono l'unione e l'inferenza aplotipo. Anche l'analisi di imputazione sarà comunemente utilizzata nel prossimo futuro.
Come attuale utilizzo, l'applicazione richiede invocazioni multiple con differenti parametri e diventa dispensiva in termini di tempo umano. Utilizzando procedure automatiche e le risorse desktop/service grid riduceremo le richieste in termini di sforzo umano e faremo un migliore utilizzo delle risorse informatiche.

Utenti

CIC bioGUNE - Un centro di eccellenza per la ricerca biomedica

La parola "biogune" significa un sito per le bioscienze che è precisamente ciò che CIC bioGUNE: è un posto che attrae ricercatori talentuosi da tutto il mondo. Attraverso la creazione di progetti comuni con altre istituzioni scientifiche, è diventata, fin dalla sua inaugurazione nel Gennaio 2005, un centro di eccellenza per la ricerca biomedica. Conseguentemente, la missione di CIC bioGUNE è realizzare ricerca di livello internazionale focalizzata su obiettivi strategici di interesse globale ed allo stesso tempo supportare lo sviluppo dell'industria biotecnologica nei Paesi Baschi. Per raggiungere questo obiettivo è necesario, nelle parole di Charles Baudelaire, andare "nello sconosciuto per trovare il nuovo".

Soluzione

Durante l'analisi dei requisiti utente (come nell'applicazione analisi) era chiaro che PLINK è un'applicazione puramente sequenziale e che il suo uso attuale potrebbe essere notevolmente migliorato in diversi aspetti, oltre all'esecuzione parallela di differenti istanze. Uno scenario molto simile deriva dall'analisi funzionale dalla quale, attualmente, derivano due approcci abbastanza diversi (singola esecuzione e a livello di processo) che possono essere facilmente soddisfatti suddividendo lo sviluppo in due pezzi abbastanza indipendenti/specializzati:

• il primo intende interagire direttamente con l'utente che si occuperà di tutta l'analisi del flusso di lavoro, porzioni del quale potrebbero essere realizzate con risorse locali. Noi chiameremo questo "flusso di lavoro applicativo PLINK" (wPLINK) e saranno utilizzate le altre applicazioni quando sarà necessario. Uno dei benefici di questa applicazione è di migliorare l'esperienza utente con l'incapsulamento del flusso di lavoro e parallelizzare lo sforzo anche nel caso che nessuna infrastruttura grid efficiente sia utilizzata.
• la seconda applicazione (pPLINK) eseguirà la parallelizzazione reale di un singolo processo PLINK quando gli argomenti forniti lo permetteranno e destinati a girare sul server del Desktop Grid anche se potrebbe essere utilizzato dalla workstation dell'utente.

Per raggiungere questo obiettivo, l'applicazione master crea una directory speciale con un gruppo con permessi di scrittura sotto la locazione dell'applicazione master. L'applicazione master non ha alcuna logica relativa ai dati ed il suo compito è quello di creare workunit basate sui file di input e svolge un lavoro di base con il risultato. L'applicazione da linea di comando, che è il lato utente dell'applicazione master, prepara i dati di input e li divide come richiesto, copiando tutti i pezzi su questa cartella condivisa insieme ad un piccolo file metadata. Questi pezzi sono spediti verso il client del Desktop Grid per essere processato. Il file metadata descrive le workunit che saranno create e da anche all'applicazione master l'informazione richiesta per riconoscore quando tutte le wu di un singolo run sono finite, al fine di innescare l'attività di manutenzione corretta. Tutti i file relativi all'applicazione lato utente sono memorizzati in una directory differente sotto la cartella master condivisa e la comunicazione tra un'applicazione e l'altra è gestita da file presenti in quella directory.

L'architettura complessiva dell'intera soluzione è mostrata in figura. L'utente lavorerà tipicamente con wPLINK che è in grado di utilizzare entrambe le applicazioni stock PLINK e pPLINK. In aggiunta, pPLINK è disponibile anche per l'accesso diretto da parte dell'utente, per eseguire un'analisi più specifica rispetto alla precedente definizione standard del flusso di lavoro. L'applicazione pPLINK prepara l'input per l'applicazione master, memorizza in una specifica directory che è esaminata dall'applicazione master incaricata di spedire le workunit. I singoli risultati sono ricevuti e spacchettati dall'applicazione master sebbene l'attuale fusione è compiuta con l'applicazione pPLINK.

Uno degli scopi di pPLINK è quello di non far fare assolutamente alcun cambiamento al lavoro dell'utente. La wPLINK finge di disturbare per la semplificare il modo in cui l'utente lavora, prepara multiple fasi di lavorazione multiple in una singola fase.

Background

PLINK è un insieme di strumenti open-source per l'analisi dell'associazione genetica, progettato per eseguire una serie di basilari analisi su larga scala in maniera efficiente dal punto di vista dell'elaborazione.
PLINK èsi focalizza esclusivamente sull'analisi dei dati di genotipo/fenotipo quindi non c'è alcun supporto per i passi prima di questo. Attraverso l'integrazione con gPLINK e Haploview, c'è qualche supporto per la seguente visualizzazione, annotazione e memorizzazione dei risultati.
PLINK è stato sviluppato da Shaun Purcell del Centro per la Ricerca Genetica Umana (Center for Human Genetic Research (CHGR)), del Massachusetts General Hospital (MGH) e dal Broad Institute of Harvard & MIT con il supporto di altri. Per maggiori informazioni: http://pngu.mgh.harvard.edu/purcell/plink/.

Il progetto EDGeS mantiene una infrastruttura Grid che connette Desktop Grid e Service Grid.

L'infrastruttura Grid di EDGeS.

I processi di aggregazione monomera nei gruppi sono studiati in diversi rami della scienza: difetti di aggregazione nella scienza dei materiali, dinamica della popolazione in biologia, crescita delle città ed evoluzione nella sociologia, ecc. La simulazione tipica di uno scenario di aggregazione di gruppo richiede diversi giorni su un singolo processore moderno, dipendente dal numero di passi Monte Carlo (MCS - Monte Carlo Steps). Tuttavia, migliaia di scenari devono essere simulati con diverse configurazioni iniziali per avere dei risultati statisticamente affidabili. L'ambiente di esecuzione parallela può ridurre i tempi di attesa e scala il sistema di simulazione a dei valori realisticamente interessanti.

Sfida

Ci sono dati sperimentali che confermano che processi di aggregazione possono evolvere le strutture, che sono gerarchiche su molte scale, e potrebbero portare a catastrofici eventi (sfondamento, valanga, frattura, ecc.). Le teorie disponibili danno molti scenari di aggregazione di gruppo, formazioni di strutture gerarchiche e le loro proprietà di scala. Ma queste richiedono potenti risorse di calcolo per l'elaborazione gerarchica degli enormi database di dati sperimentali. La nostra applicazione SLinCA (Scaling Laws in Cluster Aggregation (Leggi di Scala nell'aggregazione di gruppo) simula diversi scenari generali di aggregazione monomera nei gruppi con molte configurazioni iniziali di monomeri (casuale, regolare, ecc... ), diversa legge cinetica (arbitraria, diffusiva, balistica, ecc...), diverse leggi d'interazione (arbitraria, elastica, non elastica, ecc...). La simulazione tipica di un processo di aggregazione di gruppo con 106 monomeri richiede, approssimativamente, 1-7 giorni su un singolo processore moderno, dipendentemente dal numero di passi Monte Carlo (MCS).
Tuttavia, migliaia di scenari devono essere simulati con differenti a) parametri di input (perlustramento parametro fisico), (b) dimensioni dei sistemi simulati (per indagare un effetto scala), (c) file di configurazione iniziale con gli stessi parametri di input (perlustrare le realizzazioni statistiche).

Esempio di struttura gerarchica nella scienza dei materiali: microscopica trasmissione degli elettroni di una struttura a cella di Cu (rame) dislocata gerarchicamente dopo una trazione.

Il porting della versione sequenziale di SLinCA in un ambiente ad esecuzione parallela può ridurre i tempi di attesa e scala il sistema di simulazione ad una grandezza realisticamente interessante con l'utilizzo di configurazioni iniziali tipiche non perfette (non solo teoriche).
Soluzione
Il calcolo dei parametri degli aggregati in evoluzione (momenti delle distribuzioni delle densità di probabilità, densità distribuzioni cumulative, esponenti di scala, ecc... ) con precisione appropriata (104-108 esecuzioni di diverse realizzazioni statistiche di insiemi di aggregazione) che saranno comparabili con le stesse precisioni statistiche dei dati sperimentali disponibili. I percorsi separati di simulazione per i differenti parametri fisici, configurazioni iniziali e realizzazioni statistiche sono completamente indipendenti e possono essere facilmente divise tra le CPU disponibili in un modo di "perlustramento parametrico" parallelo. Un grande numero di esecuzioni, necessarie per ridurre la deviazione standard nelle simulazioni Monte Carlo, sono distribuite equamente tra i processori disponibili e sono combinate alla fine per calcolare il risultato finale.

Schema semplificato del decremento/aumento della dimensione di un aggregato di gruppo simulato (esempio di un insieme di dislocazione).

Recentemente, il modello del calcolo distribuito è diventato veramente popolare per la sua flessibilità nell'uso delle risorse di calcolo donate dai pc inattivi per mezzo del Berkeley Open Infrastructure for Network Computing (BOINC) (http://boinc.berkeley.edu/). La piattaforma software BOINC è un middleware libero per il grid computing su computer desktop distribuiti volontari. In origine era stato progettato per eseguire applicazioni in molti campi della scienza: dalla matematica alla biologia molecolare, da climatologia alla astrofisica.
La disponibilità di una semplice ed intuitiva Applicazione Interfaccia di Programmazione per Distributed Computing (Distributed Computing Application Programming Interface DC-API) di SZTAKI ci permette anche (scienzati dei materiali e sviluppatori non professionisti) leggere modifiche nel codice della versione sequenziale di SLinCA e portarlo alla versione parallela. A causa dell'utilizzo del DC-API la nuova versione parallela dell'applicazione SLinCA potrebbe girare in un modello client-server con i nodi lavoratori del desktop grid distribuito (DG), sulla base di un server e client BOINC. Attualmente,k questa versione parallela dell'applicazione SLinCA, potrebbe facilmente ottenere una significativo della potenza elabrativa. L'approccio DG ci permette di utilizzare le risorse disponibili di un singolo pc temporaneamente inattivo che ora può essere connesso in un sistema grid, incrementando complessivamente la potenza elaborativa.

Risultati
Il Desktop Grid locale utilizzato per il test e su cui è stata eseguita l'applicazione SLinCA è basato sulla rete privata organizzativa dell'Istituto G.V.kurdyumov per la Fisica dei Metalli (Institute for Metal Physics - IMP). Questo DG di prova consiste di 5 pc desktop (con 11 core) divisi per categoria (con le seguenti risorse che sono tipiche della rete locale privata di IMP): 1(il più nuovo, greedy), 2 (nuovo PC), 3 (notebook), 4 (netbook) e 5 (PC eredità).

Tabella: Risultati di benckmark per CPU nel DG locale. Questi computer creano un'infrastruttura di elaborazione veramente eterogenea con circa 11 (14) ordini di differenza con i floating point MIPS (con gli integer MIPS) tra newest e Legacy (vedi tabella 1) con alcuni colli di bottiglia che abbiamo osservato duranti i test ed evitato (con la messa a un punto dei file di input e dell'applicazione abilitata per il DG) dopo le analisi dei risultati di test.

sinistra) differenza di tempi tra la versione sequenziale e quella parallela destra) incremento vs. numero di cpu utilizzate per eseguire con distribuzione non-uniforme ed uniforme delle workunit.

Più efficiente governo e aumento lineare Eseguendo parecchie istanze della versione sequenziale su numerosi pc dekstop vediamo che una significativa parte di risorse è dedicata alle successive operazioni di governo per ogni istanza eseguita dell'applicazione sequenziale: preparare i file di input dei parametri e dei dati; connetersi al pc remoto, login e controllo dello stato attuale, scaricare i risultati, se il lavoro è finito, controllare i risultati, classificarli e memorizzarli, caricarli i nuovi file di input, far ripartire una nuova istanza dell'applicazione. In generale sono necessari 5-20 minuti per ogni istanza eseguita dell'applicazione sequenziale ma in pratica questo insieme di operazioni di governo è complicato da:

1. ampia distribuzione spaziale dei pc nei locali dell'IMP (in differenti stanze, piani ed edifici);
2. il limitato numero di pc multicore nella nostra organizzazione (senza BOINC è stata dura seguire lo stato di inattività di ogni singolo core ed eseguire l'applicazione in maniera discreta per i loro utenti).
3. fattore umano: alcuni utenti non sono in grado di fornire accesso remoto ai loro pc e le operazioni di governo possono essere fatte solamente a mano e sul posto; alcuni pc non possono essere raggiunti in assenza dei loro proprietari; è impossibile non solo fare le operazioni di governo ma anche pianificarle affidabilmente; alcuni utenti dei pc dimenticano l'applicazione sequenziale in background e spengono i loro pc dopo ore di lavoro. I test con la versione parallela dell'applicazione mostrano che le seguenti operazioni di governo sono necessarie per eseguire tutte le istanze: preparare il file di input dei parametri e i dati, configurare i file XML dei client e master e aggiungere l'applicazione DG-enable al progetto BOINC

Maggiore usabilità. L'usabilità dell'esecuzione parallela di centinaia di task sulla nostra infrastruttra locale DG è molto maggiore in comparazione con la loro esecuzione sequenziale sullo stesso numero di pc. In teoria sembra essere ovvio e banale ma in pratica (in vista dei molti ostacoli originati dall'eterogeneità e dai fattori umani) crea un effetto staordinariamente affascinante avere la disponibilità immediata di risorse sui pc e cpu inattivi, partenza automatica, sospensione e ripresa di numerose workunit ed una raccolta di risultati automatica dai pc di altri e solitamente lontani. Risultati fisici: risultati qualitativamente nuovi anche a livello di prova in laboratorio Nonostante le modalità di test delle attività di cui sopra, questo moderato aumento ci permette di ottenere diversi risultati qualitativamente nuovi a causa di un significativo aumento dei calcoli anche a livello di laboratorio sul banco di prova. È stato dimostrato che la configurazione iniziale dei difetti complessi (pareti) dopo alcuni passi di aggregazione si evolvono con distribuzioni libere, che sono diverse dalle distribuzioni standard di Gauss con picchi distintivi e valori finiti di momenti secondi. Le distribuzioni iperboliche che sono state trovate per varie configurazioni iniziali con diversi numeri di difetti in ogni insieme difettoso ovvero in accordo con i modelli recentemente proposti di transizione di rumore indotto dall'omogenea distribuzione di difetti a quella libera (e frattale). In aggiunta a questo, sono state osservate diverse leggi di forza per il numero di gruppi come funzione dei passi di aggregazione, che permettono di distringuere le diverse configurazioni difettose dalla loro aggregazione cinetica.

Distribuzioni di misura di una divisoria rilassata per configurazioni iniziali con i differenti valori di difetto in ogni insieme: (left) singola (come funzione delta) distribuzione di difetti inizialmente solitari, (destra) singola (come funzione delta) distribuzione di iniziali "divisorie imperfette" con 100 difetti in ogni divisoria. Cerchi solidi denotano l distribuzione della dimensione della divisoria dopo un passo di aggregazione, triangolare -- dopo 100 passi di aggregazione.

Per scopi pratici, questi risultati indicano, che per la stima della propagazione spaziale di sottostrutture difettose e la relatica scala di danno, è necessario misurare non solo l'integrale delle caratteristiche medie degli insiemi difettosi (densità spaziale media, dimensione media, ecc...) ma anche più caratteristiche specifiche locali come dimesione della funzione distribuzione, distribuzione spaziale multiscala, evoluzione temporale, ecc... Per esempio, nei più semplici casi di analisi di scaling delle distribuzioni sperimentali di misure aggregate e scenari di aggregazione che ci permetteranno di determinare il tipo di configurazione aggregata ed il livello di evoluzione aggregata.

Funzioni distribuzione cumulativa scalate per divisorie: (sinistra) legge di scaling diffusiva; (centro) legge di scaling esponenziale e (destra) leggi di scaling miste. Le figure vicino ai simboli denotano il numero di MCS.

Background
L'istituo G.V. Kurdyumov per la Fisica dei Metalli DEll'Accademia Nazionale delle scienza dell'Ucraina ha una lunga esperienza nel campo della scienza dei materiali, simulazione dell'evoluzione della struttura dei materiali, ecc... Hanno collaborato con aziende leader nell'ingegneria aerospaziale e aeromotive, inclusa la British Aerospace, Airbus UK Ltd, ETO, ecc...- IMP ha un'esperienza di partecipazione di successo in progetti internazionali sotto la struttura dell'organizzazione europea INTAS (1999-2007) e sotto la struttura delle organizzazione intergovernative R&D (2007-2008). Maggiori informazioni su http://www.imp.kiev.ua.
XtremWeb ^HEP-E è una piattaforma informatica globale che mira ad aggregare risorse di calcolo volontarie su Internet.
DC-API è una semplice ed intuitiva interfaccia applicazione di programmazione creata da MTA SZTAKI che permette una facile implementazione di applicazioni distribuite su diversi ambienti grid. Maggiori informazioni su http://www.desktopgrid.hu/index.php?page=34.

Il riconoscimento dei carboidrati è un fenomeno critico per un certo numero di funzioni biologiche negli umani, incluse risposte altamente specifiche del sistema immunitario ad agenti patogeni, l'interazione e la comunicazione tra le cellule. Questo tipo di studio potrebbe consentire ai bio-scienzati di capire come agenti patogeni si legano alla superficie delle cellule proteiche e aiutare nella progettazione di vaccini basati sui carboidrati ed agenti diagnostici e terapeutici. Programmi di simulazione possono aiutare con successo lo studio di tali processi complessi riducendo il costo degli esperimenti di laboratorio in umido e migliorare l'efficienza temporale.

Sfida
Il progetto ProSim (Protein Molecule Simulation on the Grid - Simulazione molecole delle proteine sul Grid) ha creato con successo un grid basato su un flusso di lavoro che perlustra parametri per lo scenario descritto sopra utilizzando il portale WS P-GRADE. Il flusso di lavoro realizza un complesso scenario utente, come illustrato nella figura sotto. In primo luogo, la proteina recettore e i glicani sono modellati separatamente e l'energia è minimizzata con l'aiuto del software di dinamica molecolare Gromacs (rappresentata dalle fasi 1 e 2, rispettivamente, sulla figura). Nella fase 3 il presunto legame di siti attivi coinvolti nel riconoscimento deve essere identificato utilizzando il software di simulazione di docking, come AutoDock (fase 3). Infine, le simulazioni di dinamica molecolare sono applicate nuovamente per selezionare il meccanismo di riconoscimento (fase 4).
La fase 3 del flusso di lavoro sottostante utilizza il software di simulazione di docking molecolare AutoDock per identificare i presunti siti attivi di legame coinvolti nel ricoscimento basato su un algoritmo di ricerca genetica. L'efficienza di questa fase di docking può essere ulteriormente migliorata con un'esecuzione casuale di un grande numero di esperimenti di docking e selezionare le soluzioni con l'energia minore da un potenziale numero di simulazioni, eseguite, enorme.

Utenti
Gli utenti primari dell'applicazione sono bio-scienzati del Dipartimento di Bioscienza Molecolare e Applicata dell'Università di Westminster. Tuttavia, il software Autodock è il software di simulazione più utilizzato nello studio del docking molecolare e quindi è di grande interesse per un numero crescente di bio-scienzati di tutto il mondo. Diverse communità utenti di EGEE, per esempio la communità WISDOM,  utilizzano AutoDock.

Soluzione
Al fine di indirizzare le seguenti sfide, le simulazioni AutoDock devono essere eseguite diverse volte, nella serie di migliaia o decine di migliaia, con gli stessi file di input. Una simulazione può richiedere diversi minuti od ore su un pc standard, dipendente dalla complessità delle molecole. Tuttavia, questa simulazione è indipendente da ogni altra e può, potenzialmente, utilizzare un gran numero di risorse informatiche dove le simulazioni di docking sono eseguite su diversi nodi allo stesso tempo. Utilizzando un gran numero di risorse, si può ridurre significativamente il tempo di esecuzione complessivo permettendo ai bio-scienzati di analizzare e comparare un grande numero di scenari nello stesso lasso di tempo.
Il progetto EDGeS ha sviluppato un meccanismo di ponte bidirezionale che connette le risorse di g-Lite basate su EGEE service grid (SG) a diversi BOINC ed XtremWeb basati sui sistemi desktop grid. Utilizzando la tecnologia di ponte di EDGeS, risorse di entrambi i tipi di grid possono essere applicate per eseguire un gran numero di simulazioni, come il docking molecolare. Questa infrastruttura è una candidata ideale per fornire le grandi quantità di risorse richieste per la fase di docking per il flusso di lavoro di ProSim.
L'applicazione AutoDock è stata portata con successo su un Desktop Grid basato su BOINC e gira su un Desktop Grid locale all'Università di Westminster utilizzando 1600 pc. L'applicazione è, inoltre, capace di utilizzare il ponte EDGeS in entrambe le direzioni. Bio-scienziati possono eseguire l'applicazione dal portale Ws-PGRADE rendendo l'esecuzione e il recupero dei risultati facilissimo e molto più user-friendly.

Risultati
Utilizzando l'infrastruttura EDGeS, problemi su larga scala possono essere risolti 200 volte più velocemente che su una singola macchina. Questo permette ai bio-scienzati di eseguire simulazioni docking più complesse ed analizzare un grande numero di scenari rispetto a quanto era possibile in precedenza. La figura mostra il raggruppamento di 100 risultati di docking e solo la soluzione a miglior adattamento è selezionata quando il docking umano E.R. Mannosidase 1X9D nel complesso con un Thiosaccaride Substrate.

Background
AutoDock è il software di simulazione maggiormente utilizzato. Per primo AutoGrid e alcuni script addizionali, poi tutte le parti del pacchetto AutoDock, sono applicate. Lo scopo è di definire i parametri di docking, lo spazio della griglia ed il centro dello spazio di docking, seguito dal calcolo e memorizzazione dei campi di forza per diversi atomi della molecola liganda. L'attuale docking è eseguito in due stadi. Prima AutoDock traduce i ligandi in spazi geometrici finché il contatto con il recettore è creato. Poi si avvale di una semi-empirica equazione di campo di forza di desolvatazione o algoritmi simulativi di ricottura. I risultati generati possono essere visualizzati o analizzati con diversi strumenti.

L'EDGeS Application Development Method (EADM) Ë un metodo che standardizza il porting delle applicazioni ad un complesso ambiente Grid. Il metodo assicura che Ë il miglior percorso possibile da scegliere per il porting.

La metodologia EDGes Application Development utilizzata nel porting dell'applicazione al Grid.

Il progetto EDGeS mantiene una infrastruttura Grid che connette Desktop Grid e Service Grid.

L'infrastruttura Grid di EDGeS.

Lo scopo principale dell'applicazione rendering è di creare immagini e video da modelli che sono stati progettati con Blender. Il processo di rendering è a livello di elaborazione molto costoso; un'animazione molto complessa può essere renderizzata per settimane o mesi su un singolo processore. Come i frame possono essere renderizzati indipendentemente da ogni altro, il tempo di rendering può essere ridotto significativamente con il porting dell'applicazione ad una piattaforma Service o un Desktop Grid.

Sfida
Il Centro di Elaborazione Parallela dell'Università di Westminster ha impostato il servizio pubblico Rendering Portal (https://rendering-portal.cpc.wmin.ac.uk/) nel Novembre del 2008 che offre limitate ma libere capacità di rendering per la communità utente di Blender (Blender è una delle applicazioni open source di rendering utilizzate). Il portale ha attirato più di 1200 utenti nel suo primo anno di operatività. Gli hanno hanno spedito 464.000 frame da renderizzare ed il tempo totale di rendering sul portale fu di 28.000 ore di cpu (1167 giorni). Il feedback dagli utenti sul forum di BlenderNation fu veramente positivo ed incoraggiante. La soluzione utilizzata attualmente è una specifica versione personalizzata del portale P-GRADE Grid come interfaccia utente ed un cluster di 256 processori per eseguire i rendering. L'implementazione DG all'interno del progetto EDGeS può, significativamente, estendere il numero di processori utilizzati con l'aggiunta di risorse dal Westminster Local Desktop Grid ed altre da EGEE all'attuale infrastruttura. Anche DG pubblici possono essere impostati per uno scopo simile basati sulla tecnologia e le applicazioni sviluppate da EDGeS.

Utenti
Lo scopo della communità utenti è molto ampio e comprende tutti gli utenti del pacchetto Blender, includendo sia "amatori" entusiastici sia progettisti e ricercatori professionali. L'attuale portale di rendering ha oltre 1200 utenti prevedendo una crescita dinamica nel prossimo futuro.

Soluzione

Il portale di rendering è basato sulla tecnologia del portale P-GRADE Grid e personalizzata per le specifiche richieste dell'applicazione di rendering. Gli utenti possono creare un account sul portale online, creare nuovi lavori di rendering e caricare i file da renderizzare. Una volta che il file è caricato, il portale automaticamente genera un'applicazione flusso di lavoro e lo indirizza alle risorse disponibili. L'utente può spedire l'applicazione rendering alle risorse Grid e recuperare il frame risultante o scaricare l'animazione. Uno screenshot del portale che mostra i task di rendering e l'esecuzione di un flusso di lavoro selezionato è nella figura sottostante.
L'implementazione EDGeS utilizza il principio di parallelizzazione del lavoratore master, adatto per le infrastrutture DG. L'applicazione principale prende il frame iniziale e finale dell'animazione e li divide in più piccole parti uguali dipendenti dal numero di workunit specifiche. L'applicazione master spedisce il numero di frame iniziale e finale di quelle parti all'applicazione lavoratrice. L'applicazione lavoratrice renderizza i file della specifica immagine e li spedisce indietro all'applicazione master la quale crea un video completo da loro. Il tipo di parallelizzazione matser-lavoratore è possibile quando i frame individuali possono essere renderizzata indipendentemente da tutti gli altri.

Risultati
L'applicazione è distribuita a livello produzione sul Westminster Local Desktop Grid e le versioni EGEE e BOINC sono scaricabili dal EDGeS Application Repository. L'integrazione della versione DG a Portal Rendering è stata finita ed il nuovo portale verrà lanciato dopo i test finali.

Background

Il rendering è il processo di generazione di un'immagine da un modello per mezzo di programmi informatici. Il modello è una descrizione di oggetti tridimensionali in un linguaggio strettamente definito o in una struttura dati. Conterrebbe geometria, punto di vista, texture, illuminazione e informazioni di ombreggiatura. L'immagine è un'immagine digitale od un raster grafico. Nel caso di grafica 3D, il rendering è un processo esigente in termini di elaborazione e per la creazione di film può essere fatto come un processo separato su un'infrastruttura di calcolo potente.

L'EDGeS Application Development Method (EADM) Ë un metodo che standardizza il porting delle applicazioni ad un complesso ambiente Grid. Il metodo assicura che Ë il miglior percorso possibile da scegliere per il porting.

La metodologia EDGes Application Development utilizzata nel porting dell'applicazione al Grid.

Il progetto EDGeS mantiene una infrastruttura Grid che connette Desktop Grid e Service Grid.

L'infrastruttura Grid di EDGeS.

Frequentemente il ricovero di un paziente ha significative conseguenze organizzative per gli ospedali. Quindi il ricovero d'urgenza di un paziente può essere utilizzato come un indicatore in un quadro di valutazione delle prestazioni dove gli ospedali sono classificati sulla base sul loro livello di ricoveri.

Sfida
Nel contesto della profilazione degli ospedali, utilizzare un dataset completo non è pratico.Tuttavia, un'analisi di un gruppo gerarchico viene eseguita su tutti i pazienti di un gruppo con similarità basate sulla forma della funzione di distribuzione cumulativa della durata del ricovero (Lenght of Stay - LOS) nella communità prima del ricovero. Perciò un dataset veramente grande è decomposto in raggruppamenti di sottogruppi di pazienti che hanno un LOS simile. Questi raggruppamenti di sottogruppi di pazienti sono poi campionati ed un valore di rank (basato su un modello di transizione multilivello) è assegnato per ogni ospedale in ogni campione. Infine, i risultati provenienti dai diversi campionamenti sono aggregati per arrivare al risultato finale.
Al fine di raggiungere il livello desiderato di accuratezza, la procedura di campionamento e ranking è ripetuta diverse volte, tipicamente nell'ordine di migliaia per ciclo di produzione, e può richiedere giorni per essere completato su un singolo processore. Tuttavia, come questi campionamenti e le loro seguenti analisi sono indipendenti da ogni altra, l'elaborazione di loro può essere parallelizzata utilizzando il modello master-lavoratore ed un'infrastruttura Desktop Grid.

Utenti
Gli utenti primari dell'applicazione sono i ricercatori del Gruppo di Modellazione della Salute e della Cura Sociale dell'Università di Westminster. Tuttavia, modelli statistici basati sul pacchetto statistico R è ampiamente utilizzato in diverse discipline. Quindi l'implementazione con il progetto EDGeS può servire come un'implementazione di riferimento per altri compiti simili.

Soluzione
L'applicazione è stata portata ed eseguita sulla UK National Grid Service (NGS) prima del progetto EDGeS. Questa implementazione utilizza la versione 2.5 del portale P-GRADE grid ed implementa un flusso di lavoro con parametro mobile per esecuzioni multiple degli script d'analisi R. L'applicazione può solamente utilizzare due siti NGS (Rutherford e Westminster) dove il pacchetto R è stato pre-distribuito. Come le risorse del gruppo di destinazione potrebbe facilmente diventare un collo di bottiglia per l'esecuzione, le risorse desktop offerte da EDGeS forniscono una soluzione adatta ad eseguire l'applicazione più veloce.
Nella versione desktop grid l'applicazione master ottiene il file del gruppo con tutti i dati relativi ai pazienti. Il master, poi, estende lo script R puro con un file di comandi specfici, crea le workunit contenenti lo script R e il file del gruppo come input. L'applicazione worker risolve i file di input ed esegue lo script R nei tempi specificati su campionamenti casuali del file del gruppo. Una volta terminato, il worker spedisce i file generati in zip indietro all'applicazione master. Il master raccoglie i file di output ed esegue uno script che sintetizza gli output.

Risultati
La prestazione dell'applicazione è stata testata sul Westminster Local Desktop Grid (WLDG) con un database pazienti che contiene circa 1 milione di record. Una iterazione, che è l'analisi statistica di 1000 record casuali, è stata eseguita 100, 1000, 10000, 30000 e 100000 volte. Il massimo incremento raggiunto utilizzando le risorse desktop è stato di 300.
L'applicazione è distribuita a livello produzione sul WLDG e le versioni EGEE e BOINC sono scaricabili dal repository produzione di EDGeS.

Background
Il Dipartimento della Salute del Regno Unito rilascia annualmente il suo database nazionale, l'Hospital Episode Statistics (HES). Il dataset HES descrive un periodo di 7 anni finanziari e contiene approssimativamente 80 milioni di episodi anonimi in totale. Il Gruppo di Modellazione della Salute e della Cura Sociale dell'Università di Westminster utilizza questi dati per definire un quadro per la classifica delle prestazioni ospedaliere.
Il dataset HES è memorizzato su un database MySQL. I raggruppamenti sono estratti utilizzando algoritmi con diverse proprietà e fornisce file sotto forma di CSV (Coma Separated Variables) per campionamento ed analisi. L'analisi dei campionamenti utilizza R, un linguaggio ed ambiente per l'elaborazione statistica e grafica.

L'EDGeS Application Development Method (EADM) Ë un metodo che standardizza il porting delle applicazioni ad un complesso ambiente Grid. Il metodo assicura che Ë il miglior percorso possibile da scegliere per il porting.

La metodologia EDGes Application Development utilizzata nel porting dell'applicazione al Grid.

Il progetto EDGeS mantiene una infrastruttura Grid che connette Desktop Grid e Service Grid.

L'infrastruttura Grid di EDGeS.

I raggi X sono una tecnica utilizza frequentemente in molte aree scientifiche incluse medicina, fisica e scienza dei materiali per ottenere informazioni (come dimensione o forma) per quanto riguarda la particella colpita dai raggi X. La diffrazione dei raggi X può essere misurata e rappresentata in un grafico dove sono mostrate le minime e le massime intensità dei raggi. L'informazione della particella si ottiene mediante parametri che danno origine ai picchi nel grafico. Sfortunamente questi picchi possono sovrapporsi rendendo la distinzione tra loro e l'abbinamento per il miglior abbinamento piuttosto difficile.

Sfida
Diverse funzioni di idoneità possono essere applicate per classificare e comparare le possibili soluzioni. Se la funzione di idoneità applicata deve essere valutata per un gran numero di scenari, poi trovare la migliore soluzione di adattamento per una serie di risultati sperimentali, potrebbe essere molto intensa a livello di elaborazione. Come il tempo di elaborazione incrementa esponenzialmente con il numero di picchi nel profilo, l'analisi dei profili, con un numero sconosciuto di picchi, potrebbe essere piuttosto complessa. I risultati più precisi potrebbero essere ottenuti se tutte le possibili soluzioni della funzione di idoneità applicata sono comparate e valutate. Sfortunamente, il numero di possibili soluzioni potrebbe essere così alto che questo processo lineare di ricerca richiederebbe diversi centinaia di anni CPU per finire.

Utenti
La prima communità utenti e gli sviluppatori dell'applicazione sono i ricercatori dell'Università di Extremadura in Spagna. Tuttavia, la metodologia, se si dimostrerà efficace, ha grandi potenzialità per essere utilizzata in diverse aree di applicazione.

Soluzione
La versione originale dell'applicazione è una soluzione sequenziale che esisteva prima del progetto EDGeS. Il programma prende il numero di picchi ricercati e l'utente ne definisci il minimo, massimo e valori incrementali per ogni parametro ed esegue la funzione di idoneità per tutt le possibili combinazioni di valori dei parametri all'interno dell'intevallo dato e con l'incremento dato. Dato che un'esecuzione di una funzione di idoneità è indipendente da ogni altra esecuzione, in teoria tutte le differenti combinazioni possone essere eseguite su diversi processori in parallelo con tutti gli altri.
Tuttavia, dal momento che un'esecuzione prende solamente poco tempo, da qualche parte nel range dei 5*10^-4 secondi, il sovraccarico causato dalla distribuzione di ogni singola esecuzione su diversi computer sarebbe troppo grande rispetto al guadagno di prestazioni. Al fine di ovviare a questo problema, milioni di calcoli di funzioni di idoneità possono essere impacchettati in una workunit impiegando un ragionevole tempo di esecuzione di 20-30 minuti per ogni particolare pacchetto.
Un'altra sfida è la scala cosmica del problema. Se il numero di parametri di input è alto e l'incremento richiesto è basso, allora una grande quantità di processori richiederebbero diversi anni per risolvere il problema. Al fine di ovviare questo, la ricerca lineare è stata sostituita con un approccio iterativo. Il calcolo iniziale inizia con un alto incremento e, quindi, con un valore basso di precisione. Sebbene questo calcolo garantisce di finire in tempi raionevoli, non è adatto a fornire risultati corretti. Quindi, la precisione aumenta e l'intervallo dei parametri di input decresce durante questa iterazione, focalizzandosi sugli intervalli circostanti i migliori valori della precedente iterazione.

Risultati

Sfortunatamente, i risultati scientifici non erano quelli aspettati. Iniziare con una bassa precisione scartava automaticamente alcune possibili soluzioni perdendo alcune delle migliori soluzioni. La modifica dell'approccio lineare ha generato dei risultati significativamente più deboli quando sono stati comparati agli altri approcci, per esempio quando è stato utilizzato l'algortimo evoluzionario. Dopo l'analisi dei risultati, il team di ricercatori ha scartato l'approccio della modifica della ricerca lineare ed investigherà su altre tecniche, come diversi tipi di algoritmi evoluzionari, per quanto riguarda la loro idoneità al problema.

Background

L'EDGeS Application Development Method (EADM) Ë un metodo che standardizza il porting delle applicazioni ad un complesso ambiente Grid. Il metodo assicura che Ë il miglior percorso possibile da scegliere per il porting.

La metodologia EDGes Application Development utilizzata nel porting dell'applicazione al Grid.

Il progetto EDGeS mantiene una infrastruttura Grid che connette Desktop Grid e Service Grid.

L'infrastruttura Grid di EDGeS.

I dati rappresentano un problema critico per gli scienzati ed, in particolare, per gli astronomi. Strumenti di osservazione (telescopi, satelliti, ecc...) producono enormi quantità di immagini e informazioni. Computer e simulazioni numeriche generano un'enorme quantità di dati. Tutti questi dati devono essere memorizzati, gestiti ed analizzati. Questi passi richiedono un notevole sforzo umano, grandi impianti e strumenti efficienti e potenti.

Sfida

VisIVO (che sta per Visualization Interface for the Virtual Observatory) è un pacchetto per il supporto alla visualizzazione e l'analisi di dati astronimici in 3-dimensioni. Questo strumento fornisce una visualizzazione grafica in 3D dei dati sfruttando le più avanzate tecnologie di visualizzazione ed ha diversi strumenti all'interno che forniscono un modo efficace ed intuitivo di gestire ed analizzare una grande quantità di dati prodotti con le osservazioni e le simulazioni numeriche. VisIVO può trattare dati sia osservazionali che teorici (es. prodotti attraverso simulazioni numeriche) ed è particorlarmente efficace nella manipolazione dei dataset multidimensionali (es. cataloghi, maglie di calcolo, ecc...). Può essere utilizzato sia come applicazione stand-alone, che agisce sui file locali, sia come un'interfaccia per il framework Virtual Observatory, da cui si possono recuperare i dati.
La suite di software VisIVO era disponibile prima sul progetto EDGeS in due forme: una suite software stand-alone per desktop ed una versione per grid. Se utilizzato come un'applicazione stand-alone, l'utente può lavorare sui file locali in un ambiente Windows con una semplice interfaccia. La versione grid è stata portata ed eseguita sul Cometa Consortium Grid precedentemente al progetto EDGeS. La motivazione del porting dell'applicazione alla piattaforma EDGeS è stata quella di utilizzare il grande numero di risorse a livello di produzione comparate le soluzioni esistenti.

Utenti

La communità scientifica ha mostrato un grande interesse negli strumenti scientifici di visualizzazione. Gli utenti primari di questa applicazione sono astrofisici, chi può utilizzare lo strumento per comprendere effettivamente la distribuzione tre-dimensionale dei campi, la loro geometria, topologia o specifici modelli. Visualizzare ed analizzare i dati astrofisici è a livello di elaborazione intenso e potrebbe richiedere giorni o settimane su un singolo pc per essere completate. La versione Grid dell'applicazione permette lo sfruttamento della potenza di calcolo sufficiente per comprendere le simulazioni su una larga scala ed in un tempo minore che permettono a grandi communità di ricercatori di utilizzare la suite di software VisIVO Server.

Soluzione

L'applicazione VisIVO Server ha tre componenti. Solo una delle applicazioni nella suite richiede notevole potenza computazionale: VisIVO Viewer. Gli altri due componenti (VisIVO Importer, VisIVO Filters) possone essere eseguiti dall'utente sul suo PC visto che il loro tempo di esecuzione è relativamente breve. L'utente prima esegue VisIVO Importer per convertire i dati di input in un formato dati interno (VisIVO Binary Table, VBT). Ulteriori modifiche e trasformazioni possono essere effettuate sul file VBT con l'applicazione di vari VisIVO Filters su di esso. Con il VBT file ed altri file di input necessari, l'utente è pronto per eseguire il VisIVO Viewer. Eseguire il VisIVO Viewer è il compito più intensivo a livello di elaborazione. Questo componente renderizza i frame dal file VBT.
L'implementazione EDGeS utilizza il principio di parallelizzazione master-worker adatto all'infrastruttura DG. L'applicazione master ricevi in ingresso la tabella dati ed il file parametro e crea diversi file di parametro uguali dipendenti dal numero di workunit. L'applicazione master spedisce il numero di frame iniziale e finale in quei file parametro all'applicazione worker. Quest'ultima (che esegue VisIVO Viewer) renderizza i file immagine specifici e rispedisce all'applicazione master il video che ha creato da loro. Il tipo di parallelizzazione master-worker è possibile quando i singoli frame possono essere renderizzati indipendentemente da ogni altro.

Risultati

L'applicazione è stata testata con successo ed è disponibile per l'esecuzione su un desktop grid basato su BOINC ed anche in entrambe le direzione sul EDGeS EGEE BOINC bridges.
L'applicazione è stata sviluppata a livello di produzione sul Westminster Local DG (WLDG) e le versioni EGEE e BOINC sono scaricabili dal EDGeS Application Repository.
Le prestazioni dell'applicazione sono state testate e valutate sulla piattaforma WLDG. Le prestazioni di un singolo processore di un PC test sono state comparate con un grande ma non determinato numero di computer (circa 1500) utilizzati nel desktop Grid sperimentale. Durante i test la versione DG dell'applicazione è stata eseguita 300 volte più velocemente della versione originale.

Background

L'EDGeS Application Development Method (EADM) è un metodo che standardizza il porting delle applicazioni ad un complesso ambiente Grid. Il metodo assicura che è il miglior percorso possibile da scegliere per il porting.

La metodologia EDGes Application Development utilizzata nel porting dell'applicazione al Grid.

Il progetto EDGeS mantiene una infrastruttura Grid che connette Desktop Grid e Service Grid.

L'infrastruttura Grid di EDGeS.

Cliccare sulle icone relative alle "Applicazioni" e allo "Stato del server" .

Per unirsi al team BOINC.Italy consultare la scheda "Link" qui a destra cliccando sull'icona relativa al "JOIN" .

Cliccare sulle icone relative alle "Statistiche progetto" o alla "Classifica utenti" (solo per iscritti al team).

Cliccare sulle icone relative alle "Statistiche del team sul progetto" o alla "Classifica dei team italiani" .