ATLAS Computing Model Lamberto Luminari CSN1 - 31 Gennaio, 2005.

Slides:



Advertisements
Presentazioni simili
Tecnologia delle basi di dati: Strutture fisiche di accesso
Advertisements

Gestione della memoria centrale
E835 & Hera-B Concezio Pisa, 21/12/2004. E835 (aka Jet-FNAL) timeline dell'esperimento –Presa dati conclusa nel Alcune analisi tuttora in corso.
Run I Distribuzione inclusive di Min Bias (Mult. Carica, Pt). Correlazioni dello stato finale ( -Mult) + mini-jet (soft hard physics). Campioni utilizzati:
Unità D2 Database nel web. Obiettivi Comprendere il concetto di interfaccia utente Comprendere la struttura e i livelli che compongono unapplicazione.
Miglioramento della protezione dei dati mediante SQL Server 2005 Utilizzo della crittografia di SQL Server 2005 per agevolare la protezione dei dati Pubblicato:
File System Cos’è un File System File e Directory
Time Sharing Il termine “Time Sharing” proviene dall'inglese e significa letteralmente “partizione di tempo”. Questa è una tecnica sviluppatasi negli.
Interfaccia del file system
Realizzazione del file system
L. Perini CSN1 -Roma 23 Gen Centri Regionali per il calcolo di ATLAS in Italia Tier-1 e Tiers-N : funzioni, localizzazione, necessita di h/w, personale.
Alessandra Doria III Workshop Software e Calcolo Moderno Martina Franca Ottobre 1999 La presentazione degli istogrammi nel sistema di Monitoring.
Introduzione alle attivita Software e Computing di Atlas Napoli M. Biglietti – G. Carlino – F. Conventi - A. Doria – L. Merola - A. Migliaccio Software:
1 La farm di ATLAS-Napoli 1 Gb/s 7 nodi con 2 CPU PIII a 1 GH, RAM 512 MB, 2 schede di rete a 100 Mb/s. Server con 2 CPU PIII a 1 GH, RAM 1 GB, 2 schede.
Introduzione agli stream e alle classi
Test del Monitoraggio del Tracker usando un Tier2 M.S. Mennea, G. Zito, N. De Filippis Università & INFN di Bari Riunione Consorzio – Torino 18 Novembre.
Primi Elementi di Programmazione in C++
Strutture dei sistemi di calcolo Funzionamento di un sistema di calcolo Struttura di I/O Struttura della memoria Gerarchia delle memorie Architetture di.
ADSL VOIP Voice Over IP.
Tier1 - cpu KSI2k days ATLAS KSI2k days CMS. Tier1 - storage CASTOR disk space CMS requires: T1D0, T0D1 ATLAS requires: T1D0, T0D1 and T1D1.
Software per il b-tagging Gabriele Segneri Firenze, 16 Gennaio 2003.
Il software delle DT Attività in corso Stato della simulazione e ricostruzione hit in ORCA Calibrazione Validazione con dati di Testbeam Testbeam Ottobre.
INTRODUZIONE l sistema operativo è il primo software che lutente utilizza quando accende il computer; 1)Viene caricato nella memoria RAM con loperazione.
La progettazione di un sistema informatico
DAGLI ARCHIVI AI DATABASE
U N INFRASTRUTTURA DI SUPPORTO PER SERVIZI DI FILE HOSTING Matteo Corvaro Matricola Corso di Reti di Calcolatori LS – Prof. A. Corradi A.A.
ACCESS Introduzione Una delle necessità più importanti in informatica è la gestione di grandi quantità di dati. I dati possono essere memorizzati.
Basi di Dati e Sistemi Informativi
Dati e DBMS DBMS relazionali SQL Progettazione di una base di dati Programma del Corso.
Reti di calcolatori LS Manni Tiziano  IT e nuovi scenari applicativi …  … portabilità dei dati …  … condivisione dati …  … disponibilità.
P.L. Fabbri Gli Hard Disks sono oggetti molto affidabili. Strategie di Backup dei dati … fino a che non si guastano !!!
INFN-BOLOGNA-T3 L. Rinaldi I siti Tier-3 nel modello di calcolo di Atlas Configurazione del sito INFN-BOLOGNA-T3 Attività di Analisi e Produzione Attività.
ATLAS Distributed Analysis Lamberto Luminari CSN1 – Roma, 16 Maggio 2006.
Analysis unibo una proposta. Work flow di una tipica analisi 1.Simulazione di piccoli campioni di eventi per studio segnale 2.Generazione in grande.
Progettazione Logica Il prodotto della progettazione logica è uno schema logico che rappresenta le informazioni contenute nello schema E-R in modo corretto.
Ricostruzione dei muoni: Stato e piani futuri. Roma, 13 settembre 2001 Gruppo Moore Gruppo 1 Premesse Nel panorama della ricostruzione dei muoni il package.
1 Gestione della Memoria. 2 Idealmente la memoria dovrebbe essere –grande –veloce –non volatile Gerarchia di memorie –Disco: capiente, lento, non volatile.
INTERFACCE Schede elettroniche che permettono al calcolatore di comunicare con le periferiche, che possono essere progettate e costruite in modo molto.
Gestione del processore (Scheduler)
Dati e DBMS DBMS relazionali SQL Progettazione di un DBMS Normalizzazione Programma del Corso di Basi di Dati.
CSN Maggio 2005 P. Capiluppi Il Computing Model (LHC) nella realta’ italiana u I Computing models degli esperimenti LHC gia’ presentati a Gennaio.
1 LHCb Computing Angelo Carbone, INFN-CNAF CSN1, 21/9/06 Aggiornamento richieste Tier Richiesta Tier-2 al CNAF Stato e risultati DC06.
Basi di dati distribuite Prof. M.T. PAZIENZA a.a
Preparazione RRB Commissione Scientifica Nazionale I 1-2 aprile 2003 S. Patricelli Consuntivo fondi M&O 2002 Divisione tra subdetectors dei fondi extra-CORE.
1 Gestione della Memoria Capitolo Introduzione alla gestione della memoria 4.2 Swapping 4.3 Memoria virtuale 4.4 Implementazione 4.5 Algoritmi di.
Dati e DBMS DBMS relazionali SQL Progettazione di una base di dati Normalizzazione Programma del Corso.
Progettazione Logica Il prodotto della progettazione logica è uno schema logico che rappresenta le informazioni contenute nello schema E-R in modo corretto.
Sistemi operativi di rete Ing. A. Stile – Ing. L. Marchesano – 1/18.
Progettazione di basi di dati: metodologie e modelli
Corso di Laurea in Biotecnologie corso di Informatica Paolo Mereghetti DISCo – Dipartimento di Informatica, Sistemistica e Comunicazione.
Tier-2 Tier-2 ATLAS (Osservazioni sulla proposta dei referee del calcolo LHC) Lamberto Luminari CSN1 – Roma, 3 Aprile 2006.
Tier-2 ATLAS Tier-2 Lamberto Luminari CSN1 – Roma, 10 Ottobre 2005.
20 Ottobre 2005CCR - Roma1 I centri di calcolo distribuiti in LHC: motivazioni, funzioni, implementazione P. Morettini.
Le basi di dati.
CDF Calcolo Another brick in the wall Paolo Morettini CSN1 Lecce Valerio Vercesi Settembre 2003.
Implementazioni di un analizzatore di protocollo Esistono quattro fondamentali tradeoff per la realizzazione di un analizzatore di protocollo:  Analisi.
D. Martello Dip. Fisica - Lecce Sintesi piani esperimenti CSN2 CNAF 7-marzo-2007.
Domenico Elia1Riunione PRIN STOA-LHC / Bologna Attività per ALICE: sommario e prospettive Domenico Elia Riunione PRIN STOA-LHC Bologna, 18 Giugno.
Gestione delle periferiche. Le periferiche sono dispositivi che permettono le operazioni di input/output.
Parma, 22 Settembre 2010 G. Carlino – ATLAS, Attività di 7 TeV 1 ATLAS Attività di TeV Attività di computing Attività di computing.
Campionamento procedimento attraverso il quale si estrae, da un insieme di unità (popolazione) costituenti l’oggetto delle studio, un numero ridotto di.
FESR Trinacria Grid Virtual Laboratory PROGETTO “MAMMO” Sviluppo e ottimizzazione di algoritmi adattativi, specificatamente di Artificial.
Atlas TDAQ E. Pasqualucci INFN Roma. Sommario Attivita’ di fine 2008 – inizio 2009 Preparazione per i run con fasci Trigger con luminosita’ iniziali 16/9/20092E.
ATLAS NAPOLI Software & Computing e il Tier-2 Gianpaolo Carlino INFN Napoli Il gruppo ATLAS di Napoli Le attività Software & Computing Il prototipo Tier-2.
1 Bari, 21 Settembre 2011 G. Carlino – ATLAS: il calcolo ATLAS: il Calcolo Attività di Computing nel 2011 Attività di Computing nel 2011 Richieste Tier2.
Il calcolo per l’esperimento GERDA Luciano Pandola INFN, Laboratori del Gran Sasso Riunione della CSN2, LNF Frascati, 29 Novembre 2011.
Esigenze di Rete degli Esperimenti LHC e di Gr1 G. Carlino – INFN Napoli CCR – Roma 8 Settembre 2014.
Lamberto Luminari CSN Maggio 2005
ATLAS Computing 2008 (Attività, risorse necessarie e richieste)
ATLAS Italia Computing Richieste 2007 (Tier-2 e locali)
Transcript della presentazione:

ATLAS Computing Model Lamberto Luminari CSN Gennaio, 2005

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model2 Sommario Introduzione Event Data Model Tempo di processamento Infrastruttura di calcolo a tier Tier0, Tier1, Tier2, Tier3 Infrastruttura di calcolo Event data flow: Streaming, EF -> Tier0, ESD, AOD, TAG Catalogazione, replica e distribuzione dei dati Modelli di analisi Risorse Tier1, Tier2 Timeline

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model3 Introduzione Il modello di calcolo attuale presenta ancora margini di indeterminazione si cerca di mantenere flessibilità ovunque possibile Le risorse presentate come necessarie derivano dal modello attuale e si basano sulle seguenti condizioni di operazione: Luminosità:2007: 100 giorni a 0.5 x cm -2 s : 200 giorni/anno a 2 x cm -2 s e oltre: cm -2 s -1 (luminosità di disegno) Frequenza di trigger:200 Hz (indipendentemente dalla luminosità) Frequenza di collisioni:10 9 Hz alla luminosità di disegno Tempo di data-taking: 50k sec/giorno Numero di eventi reali:10 7 eventi/giorno -> 2 x 10 9 eventi/anno Numero di ev. simulati:20% eventi reali -> 4 x 10 8 eventi/anno Rimangono molte incognite, e in particolare: La strategia per la calibrazione e l’allineamento è ancora in evoluzione Si inizierà a testare lo schema completo di accesso ai dati tra qualche mese improbabile uno schema stabile prima del 2007 La dimensione dei vari tipi di dati e il tempo di processamento relativo sono solo stime E’ possibile che il modello debba adeguarsi a una disponibilità di risorse diversa da quella ipotizzata

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model4 Raw Data: – –eventi in formato “ByteStream” prodotti dalla catena di TDAQ; in genere costruiti dagli Event Builders e trasmessi in output dall’Event Filter (l’ultimo stadio degli High Level Trigger): 1.6 MB/evento nominali Event Summary Data (ESD): – –l’output completo della ricostruzione in formato POOL ROOT; sufficiente per quasi ogni applicazione (eccetto che per calibrazioni e sviluppo algoritmi di ricostruzione): obiettivo: 500 KB/evento Analysis Object Data (AOD): – –rappresentazione dell’evento ridotta, derivata dagli ESD, conveniente per l’analisi, in formato POOL ROOT; contiene gli oggetti fisici e altri elementi di interesse per l’analisi: obiettivo: 100 KB/evento Tag Data (TAG): – –informazioni essenziali sugli eventi per permettere un’efficiente identificazione e selezione degli eventi di interesse per una data analisi; per facilitarne ed ottimizzarne l’accesso sono memorizzati in un database relazionale: obiettivo: 1 KB/evento Derived Physics Data (DPD): – –rappresentazione tipo n-tupla dei dati dell’evento per l’analisi e la istogrammazione dell’utente finale; inclusa nel data model per permettere un’analisi immediata e la visualizzazione dei risultati con i tanti tool standard di analisi (PAW, ROOT, JAS, …) Simulated Event Data (SIM): – –una gamma di tipi di dati, a cominciare dagli eventi generati (ad es., con Pythia o programmi simili) alla simulazione delle interazioni con l’apparato (ad es., hits di Geant4) e della risposta dei rivelatori (digitizzazione); possono anche includere il pileup e il fondo di caverna; memorizzati come file POOL ROOT (in genere) o in formato bytestream per studi di trigger: spesso  2 MB/evento Event Data Model

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model5 Simulazione (includendo generazione dell’ evento, tracciamento con Geant4, digitizzazione): – –100 kSI2ksec/evento nominali attualmente 2-4 volte maggiore, a seconda dalla fisica, ma: – –si assume di poter guadagnare un fattore 2 dal lavoro di ottimizzazione nel (questa è la prima reale implementazione con Geant4 della simulazione ATLAS) – –si assume di poter guadagnare un ulteriore fattore 2 limitando il tracciamento a |η|< 3 invece che |η|< 6 quando non strettamente necessario Ricostruzione: – –15 kSI2ksec/evento nominali a tutte le luminosità: attualmente 4 volte maggiore, ma: – –si assume di poter guadagnare un fattore 2 dal lavoro di ottimizzazione nel ; – –attualmente si utilizzano 2 algoritmi in parallelo per Inner e Muon Detector; – –le soglie possono essere accordate con la luminosità per compensare l’aumento dei tempi necessari per il pattern recognition Analisi: – –0.5 kSI2ksec/evento nominali per analisi sugli AOD stima basata sui tempi di accesso attuali agli AOD – –0.5 kSI2ksec totali per analisi su collezioni complete (tutti i dati di un anno) di DPD; (nella vita reale saranno piu’ frequenti analisi su campioni ridotti (1-10% dei dati) ma ripetute molte volte) stima basata sui tempi di accesso attuali alle n-tuple Tempi di processamento

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model6 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Infrastruttura di calcolo a tier ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1  Il modello di calcolo di ATLAS presenta un elevato grado di decentramento e fa essenziale affidamento sulle risorse esterne al CERN e sulla loro condivisione.  Pur essendo basato in modo sostanziale sul paradigma Grid, il modello mantiene ruoli ben definiti e distinti ai diversi elementi che compongono l’infrastruttura di calcolo, secondo il modello gerarchico a tier sviluppato nell’ambito del progetto MONARC.  Ai centri ai vari livelli sono assegnati compiti primari e compiti di sussidiarietà, da svolgere qualora i centri deputati siano temporaneamente impossibilitati.  Accanto alla struttura primaria (gerarchica), esistono strutture orizzontali che legano tra di loro centri dello stesso livello, con funzioni sia complementari che sussidiarie.  Il modello fissa essenzialmente la tipologia e la qualità delle risorse e dei servizi che le facility ai vari livelli devono fornire: centri dello stesso rango possono differire in dimensione (compatibilmente con gli impegni contrattati con la Collaborazione). Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k – 2 PB/y

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model7 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Ruolo del Tier0 ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1  Il Tier0 è responsabile dell’archiviazione e della distribuzione ai Tier1 (e Tier2) dei dati RAW, ricevuti dalla catena di TDAQ.  Processa velocemente gli stream di calibrazione e espressi.  Ricostruisce gli eventi (utilizzando le costanti di calibrazione calcolate) e produce i dataset derivati (ESD, AOD e TAG “primari”).  Distribuisce i dataset derivati ai Tier1.  In caso di problemi di processamento o trasmissione, memorizza i dati in un disk buffer che corrisponde a ~ 5 giorni di presa dati. Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model8 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Ruolo dei Tier1 ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1  Il modello prevede circa 10 Tier1.  Ogni Tier1 tiene in archivio 1/10 dei RAW data e ne garantisce l’accesso a lungo termine.  Ogni Tier1 tiene copia di 1/5 degli ESD e di tutti gli AOD e TAG (la versione più recente su disco, le precedenti eventualmente su mass storage a più lento accesso).  I Tier1 ospitano e rendono velocemente accedibili i campioni di eventi simulati prodotti nei Tier2 che a loro fanno riferimento.  I Tier1 devono garantire la capacità ci calcolo necessaria a riprocessare ed analizzare tutti i dati ivi residenti (Grid!).  Le risorse dichiarate devono essere disponibili a tutta la Collaborazione (ancora Grid!).  Il livello dei servizi, in termini di affidabilità e tempi di risposta, deve essere elevato; non dovrebbero verificarsi interruzioni superiori alle 12 ore e, in caso di periodi più lunghi, è previsto che un altro dato Tier1 fornisca almeno accesso agli stessi dati. Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model9 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Ruolo dei Tier2 ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1  I Tier2 assumono un ampio spettro di ruoli e funzioni, in particolare per le calibrazioni, la simulazione e l’analisi.  La loro dimensione e il tipo di risorse può variare sensibilmente a seconda delle attività e della dimensione dei gruppi di fisica che vi fanno riferimento.  Un Tier2 ospiterà tipicamente 1/3 degli AOD correnti e tutti i TAG. Ospiterà anche i DPD di interesse locale e campioni di RAW data e ESD per analisi e sviluppo algoritmi.  I Tier2 forniscono tutta la capacità di simulazione necessaria alla collaborazione; a meno che un Tier2 non riesca a garantirne esso stesso l’accesso in modo veloce e affidabile, i dati simulati saranno migrati al Tier1 di riferimento (si ipotizzano circa 4 Tier2 per ogni Tier1).  Alcuni centri, a seguito del coinvolgimento della comunità locale in un rivelatore, potranno avere un ruolo rilevante nelle procedure di calibrazione e allineamento. Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model10 Event Builder Event Filter ~7.5 MSI2k 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Ruolo dei Tier3 ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1  Il ruolo dei Tier3 è meno definito di quello dei centri di rango superiore, comunque nel modello attuale essi assumono una importanza rilevante nella simulazione e l’analisi degli utenti singoli.  La loro dimensione e il tipo di risorse può variare sensibilmente a seconda delle attività e del numero degli utenti che vi fanno riferimento.  Contengono DPD e campioni di AOD e ESD per analisi specifiche e sviluppo algoritmi.  Il controllo delle risorse (allocazione, priorità, condivisione, …) è completamente sotto controllo locale.  I Tier3 costituiscono un importante buffer di risorse per fronteggiare tutte le inefficienze o gli imprevisti non esplicitamente considerati nel modello di calcolo. Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y Tier3

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model11 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Data Flow: Streaming ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 Stream di dati principali dagli High Level Trigger (LV2 + EF): Stream primario, contenente tutti gli eventi di fisica Express line Eventi di calibrazione: processamento veloce (risorse dedicate in situ) calibrazione fine (Tier2) Stream per debugging e diagnostica Obiettivi principali dello streaming: Ridurre la latenza per un sottoinsieme di eventi (in particolare quelli di calibrazione) Processare lo stream primario con i risultati ottenuti dallo stream di calibrazione Risorse necessarie: La calibrazione veloce e la express line dovrebbero occupare ~20% di bandwidth e CPU LV2 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model12 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec 5 PB/anno ~ 75MB/s  622Mb/s links ~10 Data Flow: EF -> T0 ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y Assunzioni: 200 Hz * 1.6 MB/evento 320 MB/second ~30-50 manager di subfarm dell’EF riempiono file con eventi in formato bytestream I file di eventi sono statisticamente equivalenti nella miscela di eventi che contengono (cioè, le subfarm EF sono identiche, non specializzate per processare certi tipi di eventi) Modello: I file sono riempiti fino a 2 GB e poi subito inviati al Tier0 Ogni manager di subfarm dell’EF chiude un file approssimativamente ogni secondi I file contengono eventi di un solo run alcuni file corti ma gestione dati semplificata Gli eventi non possono essere scritti su più file La dimensione degli eventi, anche i più complessi, è piccola rispetto a quella del file gestione dati semplificata senza imporre condizioni gravose

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model13 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Produzione di dati primari derivati ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 Tier1 2. MSI2k - 2 PB/y Tier0 5. MSI2k - 5 PB/y ESD: La produzione degli ESD primari è fatta su una farm al Tier0 Il flusso di dati primario della ricostruzione è: file bytestream -> ESD I processi di ricostruzione operano su file completi, non eventi singoli Ogni processo di ricostruzione scrive gli ESD su persistent storage indipendentemente Ogni processo scrive un singolo stream di ESD in output nessuna suddivisione iniziale in base al trigger o al canale di fisica; streaming possibile successivamente AOD: La produzione degli AOD primari è fatta al Tier0 Gli AOD devono poter essere prodotti a partire dai soli ESD Ogni processo di produzione scrive gli AOD su persistent storage indipendentemente A differenza di quanto avviene per gli ESD (almeno inizialmente), un singolo processo scrive eventi AOD su stream differenti per differenti physics working group Gli stream di AOD primari sono limitati in numero a O(10), a seconda del tipo di trigger o del canale di fisica o del physics working group o…: la scelta dipende dal coordinamento per la fisica Altri stream di AOD saranno possibili in fase di ricostruzioni successive ai Tier1 Ogni evento è scritto su un solo stream primario Tutti gli stream primari formano una partizione disgiunta del run Tutti gli stream primari condividono esattamente la stessa definizione di AOD Piu’ semplice accedere a eventi su stream separati Le liste di file AOD non sono previste essere l’interfaccia primaria ai dati per il fisico medio

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model14 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Collezioni di eventi ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y Modello: Ogni processo che produce AOD inserisce anche i riferimenti agli eventi (insieme ai meta-dati relativi) in collezioni di eventi Un gruppo di analisi che non ha il suo stream primario di AOD può in linea di principio avere la sua collezione, che gli permette di accedere agli eventi di interesse con efficienza Ogni processo scrive la sua collezione su un file, per evitare problemi di accesso concorrente al database Un processamento successivo concatena le varie collezioni, che sono su file, in collezioni residenti su database, opportunamente indicizzate per velocizzare l’accesso alle informazioni vengono popolati i database di TAG Le collezioni risultanti costituiscono la base per la produzione di collezioni secondarie e altri dati derivati in fasi successive di processamento opportune query ai database permettono di estrarre sottocampioni di eventi con relativi riferimenti

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model15 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Replica e distribuzione dei dati ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 RAW:  Una replica completa dei raw data risiede nei Tier1 (~1/10 per Tier1)  Campioni di eventi sono memorizzati anche nei Tier2 e, in misura minore, nei Tier3 ESD:  Tutte le versioni degli ESD sono replicate e risiedono in almeno due dei Tier1  Gli ESD primari sono spediti dal Tier0 a un Tier1; in caso di successo, possono essere cancellati dal Tier0 (riprocessing solo ai Tier1)  Gli ESD primari e i RAW data asswociati sono assegnati ai ~10 Tier1 con un meccanismo di roundrobin  La replica degli ESD su un secondo Tier1 è un compito Tier1 -> Tier1 che può essere eseguito con comodo (ad es., quando non c’è data taking?); in ogni caso, il Tier0 non è coinvolto.  Campioni di eventi sono memorizzati anche nei Tier2 e, in misura minore, nei Tier3 AOD:  Sono replicati completamente in ogni Tier1 e parzialmente nei Tier2 (~1/3 – 1/4).  Alcune stream possono essere memorizzate nei Tier3 TAG:  I database dei TAG sono replicati in tutti i Tier1 e Tier2 DPD:  Nei Tier1, Tier2 e Tier3 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model16 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Modelli di analisi ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 Produzione centrale schedulata di AOD, n-tuple e TAG dagli ESD: Si assume che ci saranno ~20 gruppi di analisi Ogni canale di analisi può richiedere varie iterazioni, accedendo a: TAG di tutti gli eventi sottocampioni di AOD eventuali (pochi) ESD pochissimi eventi RAW Una riduzione al 10% di tutti gli AOD per gruppo, 2 versioni 125 TB ad ogni Tier1 Produzione in quasi real time di DPD 13 MSI2k Analisi caotica di singoli utenti di AOD e n-tuple, nuove selezioni, simulazioni particolari, etc.: Si assume che ci siano 600 utenti offsite (+100 al CERN), ciascuno dei quali analizza il 10% dei campioni dei gruppi di analisi (quindi 1% del totale degli AOD + pochissimi ESD) tiene su disco due versioni dei suoi DPD 15 kSI2k and 2.1 Tb per utente Uno scenario di analisi: Si invia una query a un dataset di TAG (es., l’ultimo) residente su DB Il risultato della query serve ad individuare gli AOD relativi agli eventi selezionati Un ulteriore algoritmo di selezione può essere applicato agli eventi e il risultato puo’ essere un dataset ridotto di AOD o DPD (piu’ raramente di ESD o RAW) o direttamente una n-tupla. L’analisi di grandi campioni di eventi sarà distribuita (Grid)! Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model17 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec  622Mb/s links ~10 Risorse necessarie al Tier0 ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model18 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Evoluzione risorse al Tier0 ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model19 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec  622Mb/s links ~10 Risorse necessarie alla CERN Analysis Facility (CAF) ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y CAF

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model20 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec  622Mb/s links ~10 Evoluzione risorse alla CAF ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y CAF

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model21 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Risorse necessarie ai Tier1 ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model22 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Evoluzione risorse ai Tier1 ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model23 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Risorse necessarie ai Tier2 ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model24 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 Risorse ai Tier0/1/2 + CAF necessarie per il solo 2008 ~PB/sec Tier2 ~.5 MSI2k ~4/Tier1 Tier0 5. MSI2k - 5 PB/y Tier1 2. MSI2k - 2 PB/y Se i Tier2 devono supportare anche analisi “private”, aggiungere circa 1 TB e 1 kSI2 per utente

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model25 Event Builder Event Filter ~7.5 MSI2k Tier3 10 GB/sec 320 MB/sec ~ 75MB/s  622Mb/s links ~10 ~PB/sec Tier1 ~2. MSI2k Tier2 ~.5 MSI2k ~4/Tier1 Tier0 7.5 MSI2k - 5 PB/y

CSN1 - 31/01/2005Lamberto Luminari - ATLAS Computing Model26 Materiale di backup