Utilizzo della VO di theophys per il calcolo lattice QCD G. Andronico M. Serra L. Giusti S. Petrarca B. Taglienti.

Presentazione sul tema: "Utilizzo della VO di theophys per il calcolo lattice QCD G. Andronico M. Serra L. Giusti S. Petrarca B. Taglienti."— Transcript della presentazione:

1 Utilizzo della VO di theophys per il calcolo lattice QCD G. Andronico M. Serra L. Giusti S. Petrarca B. Taglienti

2 Introduzione al problema della QCD Lo studio delle proprieta’ della QCD, ossia della teoria che governa le interazioni tra quark e gluoni, e’ basato in gran parte su simulazioni numeriche. In particolare alcune proprieta’ interessanti non perturbative sono legate alle caratteristiche topologiche del vuoto quantistico della teoria. Questo calcolo e’ dedicato alla determinazione di precisione della distribuzione della carica topologica.

3 Studio della distribuzione della carica topologica in QCD dati “g” fit  4 = - 3 2 ≠ 0 12 4  4 =0.609  0.093 (≠0 per piu’ di 5  ) Scopo del lavoro e` di avere una rappresentazione accurata della distribuzione della carica topologica ottenuta dalla definizione basata sui fermioni di Neuberger. Lo studio, condotto su reticoli di 3(+2) diverse dimensioni, dimostra che la distribuzione non e` gaussiana. Per averne la certezza e` necessaria una statistica molto elevata. Il lavoro e`stato presentato in forma preliminare alla conferenza Lattice2006 Tucson a fine luglio 2006 (POS (LAT2006) 058 )

4 Dettagli del calcolo 1/2 Il programma e` tutto scritto in C, non fa uso di librerie esterne ed utilizza in modo decisivo il set di istruzioni “SSE2” sviluppato da Intel per i processori dal Pentium 4 in poi I 3 reticoli di dimensioni diverse richiedono 250MB, 500MB e 1.1GB di RAM Per ottenere una statistica sufficiente vengono eseguiti N programmi contemporaneamente con N diversi seed iniziali per il reticolo piu`grande N=200 ogni programma si prefigge un numero prestabilito di passi MonteCarlo

5 12 4  =6 34800=58x600 confs 1h/conf 1 job=10 confs 256MB 14 4  =6.0958 30000=120x250 confs 4h/conf 1 job=4confs 512MB 18 4  =6.2623 30000=200x150 confs 12h/conf 1 job=2confs 1.1GB Volume fisico ≈ (1.12 fm) 4 Produzione dati su INFN-Grid 16 4  =6. 0 Ph.v.(1.49 fm) 4 10000=200x50 confs 8h/conf 1job=4 confs 800 MB 14 4  =6.0 Ph.v.(1.3 fm) 4 30000=200x150 confs 6h/conf 1 job=2 confs 512MB Volumi di controllo 134800 confs ≈ 800000 ore cpu  ~1 year @ 100 CPU farm dedicata: seed configurazioniGrid jobRAM ~1 h @ * * dipendenza dal hardware e poco dall’algoritmo senza la quale l'unica possibilita` di effettuare il calcolo era l'uso delle risorse Grid

6 Dettagli del calcolo 2/2 Idealmente ognuno di questi N programmi potrebbe girare ininterrottamente fino al raggiungimento dell'obiettivo. In pratica ogni programma fa un numero limitato di passi, salva e riparte Dal 11-2005 al 4-2007 (~17 mesi) sono state utilizzate su INFN Grid circa ~800000 ore di CPU (P4 2.4GHz )pari a ~33000 giorni corrispondente ad un utilizzo medio "netto" di ~66 CPU/giorno Con "netto" si intende tutto cio` che ha portato a risultati utili, quindi togliendo i job abortiti o falliti per qualsiasi motivo

7 “Killer application” per la Grid.... perche’ ? Questo tipo di calcolo ha caratteristiche peculiari (piccolo volume, alta statistica) che lo rendono particolarmente adatto alla Grid (le applicazioni standard di lattice QCD richiedono calcolatori paralleli dedicati ad alte prestazioni): la possibilita' di dividere il calcolo in job/cpu di durata limitata (< 24 ore) codice ottimizzato per l’esecuzione su singola CPU nessuna richiesta di parallelismo file di input/output di ridotte dimensioni (<30MB) eseguibile di dimensioni ridotte (~200KB) facilmente trasportabile con il job

8 Distribuzione dei job @ INFN-Grid from GridICE

9 I primi 3 mesi del 2007 …. from GridICE

10 Cosa migliorare sulla Grid Poter fare dei run piu` lunghi = minor bookeeping si puo’ su risorse condivise? Poter specificare meglio i dettagli del hardware richiesto per il job (vedi SSE2) Parallelismo = sottomissione via 1 job grid di un codice parallelo da eseguire contemporaneamente su piu’ nodi di un cluster Stabilita’ ……

11 Problemi Job finiti risultano ancora running sul RB (dopo 24h) problema perche’ l’output job finito e’ l’input successivo workaround per risolvere il problema: controllo arrivo dell’output sullo storage remoto (ri)Distribuzione dei job in funzione degli slot liberi nei diversi siti adesso risottomissione “a mano” Affidabilita’ dei numeri del monitoring esempio con plot gridice ……

12 job mancanti In questi 3 mesi 15000 job sono sicuramente stati eseguiti correttamente visto l’output gridICE ne riporta 10673 … ??? (i job cancel vengono conteggiati da gridICE?) from GridICE

13 Conclusioni Alcuni progetti con speciali caratterstiche di calcolo di QCD su reticolo possono utilizzare la Grid con soddisfazione sfruttando il tempo non utilizzato … senza particolari “agevolazioni” L’investimento iniziale non e’ trascurabile ma per progetti ~6 mesi e’ accettabile Altri progetti teorici potrebbero avere simili benefici Il problema dei job correttamente finiti che risultano ancora “running” e’ uno dei piu’ urgenti da risolvere