Luca Lista - Capri /04/2003 Nuovo Computing Model L. Lista

Luca Lista - Capri /04/2003 Sommario Metodi di analisi attuali Motivazioni del nuovo modello di calcolo Strumenti per il Bookkeeping Nuovo modello di analisi Stato del progetto

Luca Lista - Capri /04/2003 Il processo di analisi oggi 1.Identificazione dei campioni di dati da analizzare Dati (skim, …), Monte Carlo 2.Sottomissione job di produzione per l’analisi Analisi combinatoria (D, D*, B-reco, …) Calcolo delle quantità fisiche (Fisher, thrust, missing momentum,  E, m ES ) Scrittura ntuple in formato specifico per il Working Group 3.Riduzione delle ntuple per le analisi specifiche (anche in più passi) 4.Produzione dei risultati con analisi interattiva (PAW, ROOT, fit, …) 5.Preparazione dei documenti di analisi (BAD)

Luca Lista - Capri /04/2003 Distribuzione delle produzioni Produzione dei dati e degli skim  Centralizzata, SLAC Produzioni di grosse ntuple  Responsabilità degli AWG Produzione di ntuple ridotte  Responsabilità delle singole analisi Svantaggi:  Occupazione di spazio disco non necessario per le ntuple  Duplicazione delle informazioni  Mantenimento di mini-framework di analisi per gestire le ntuple Es.: semiexcl (“IBU”), cp-framework, …

Luca Lista - Capri /04/2003 Il modelli di calcolo attuale Il modello attuale ha consentito di svolgere analisi in modo soddisfacente  Molti risultati prodotti e pubblicati senza ritardi significativi dovuti alle metodologie di calcolo Molte opinioni giudicano il modello migliorabile  In termini di prestazioni  In termini di funzionalità  In termini di flessibilità

Luca Lista - Capri /04/2003 Motivazioni per un nuovo modello Estendere il modello di calcolo attuale per l’aumento di luminosità  Prompt reconstruction  Ri-processamento  Produzione Monte Carlo Ottimizzare l’uso delle risorse  Spazio disco per gli Analysis Working Groups  Utilizzo CPU  Manutenzione del codice, … Adattarsi a metodologie future  Objectivity  Root  Grid, …

Luca Lista - Capri /04/2003 Il nuovo modello di analisi 1.Identificazione dei campioni di dati da analizzare con strumenti di bookkeeping Omogenei per dati e Monte Carlo 2.Sottomissione (e monitaggio) job di l’analisi Analisi combinatoria (D, D*, B-reco, …) Calcolo delle quantità fisiche Scrittura nuovo micro-DST ridotto contenente le informazioni per l’analisi Working Group Produzione centralizzata per tutta la collaborazione (ogni 3 mesi) 3.Riduzione dei micro-DST per le analisi specifiche 4.Produzione dei risultati con accesso interattivo ai micro-DST (ROOT, …) Oppure produzione di ntuple ridotte e istogrammi nel formato finale per l’analisi 5.Preparazione dei documenti di analisi (BAD)

Luca Lista - Capri /04/2003 Dal vecchio al nuovo modello Skim Ntuple AWG Ntuple ridotte Istogrammi AWG Skim micro ridotti Istogrammi Analysis Document prod. centrale Job AWG Job analisi Root interattivo prod. centrale + cand. compositi + user data AWG job analisi: skim ridotti + user data Root interattivo su nuovi micro Scenari intermedi possibili…

Luca Lista - Capri /04/2003 Requisiti per il nuovo modello Introduzione di nuovi Micro (= Mini ridotti)  Migliori prestazioni (~1kHz), competitive con ntuple  Output configurabile con l’aggiunta di prodotti degli algoritmi di analisi: Dati utente, Candidati compositi  Accesso interattivo (Root/Cint), per evitare proliferare di ntuple Produzione di skim  Centralizzazione della produzione per gli AWG  Deep-copy / pointer-copy prodotte a seconda delle esigenze Estensione dell’uso e funzionalità del Mini  Accesso rapido (~ 1 ora per uno specifico file, 2 settimane per in run complesso)  Esportabilità e distribuzione  Accesso ai Mini a partire dai corrispettivi Micro, se richiesto Documento ufficiale: Computing/internal/CMWG2/Requirements2.pdf

Luca Lista - Capri /04/2003 Nuovi tool di Bookkeeping Antonio Ceseracciu Alvise Dorigo Martino Piemontese

Luca Lista - Capri /04/2003 Bookkeeping: situazione attuale Tracciare i diversi data set  Diversi strumenti esistenti, non sempre consistenti: skimData GoodRun Lumi Bfreport getdata Task management  Intervento manuale richiesto per configurare i job da sottomettere  Frammentazione in job multipli a carico dell’utente

Luca Lista - Capri /04/2003 Obiettivi del nuovo Bookkeeping Migliorare l’interfaccia per gestire i data set  Definizione di concetti generali e dei costituenti di base  permettere richieste con miscele di concetti come “good run”, dati “off-” e “on-resonance”, “processato con la release x.y.z”, etc.  Semplici “short alias”  Uniformità tra dati di collisioni e simulazioni Task management  Per i job di analisi, strumenti per: Configurare Sottomettere Monitorare  Soddisferà i requisiti tipici di un sistema di produzione Il sistema di Bookkeeping funzionerà nei siti TierA  Funzionalità limitate nei siti che mantengono copie parziali dei dati

Luca Lista - Capri /04/2003 Integrazione dei diversi componenti

Luca Lista - Capri /04/2003 Nuovo modello di Analisi Mario Bondioli Guglielmo De Nardo Luca Lista

Luca Lista - Capri /04/2003 Obiettivi del nuovo modello di Analisi Integrare i Mini e i Micro Supportare prodotti aggiuntive dell’analisi all’interno dei Micro (skims)  Candidati Compositi  User Data generici Informazioni dell’evento e dei singoli candidati Fornire supporto per l’accesso ai Micro attraverso Root/CINT Migliorare le prestazioni dell’analisi all’interno del Framework  miglioramenti attraverso studi dettagliati con il profiler Fino ad ora mai fatto per Beta in dettaglio, ma solo per rec/sim  "load on demand" per i dati dell'analisi  Gamma

Luca Lista - Capri /04/2003 Candidati compositi Scrivere il risultati più costosi per il calcolo  Non è necessario ri-processare l’analisi combinatoria Inizialmente due implementazioni separate sono state portate avanti  Mini (D. Brown, G. Finocchiaro) Ricostruzione del candidato composito in fase di lettura e fit del vertice  Micro (E. Charles, G. Raven) Scrivere anche informazioni del candidato ricostruito (P4 + Vertice) I due prototipi sono stati integrati  Implementazione prototipale per i testi di Aprile  Implementazione finale per Luglio

Luca Lista - Capri /04/2003 Dati Utente Generici Supporto per quantità definite dall’utente da incorporare nei Micro-DST Esempi comuni di variabili per l’analisi:   E, m ES,  m D*,D, cos  B,D*l, … I tipi di variabili utilizzabili sono sia quelli nativi:  double, int, … Che qualsiasi altro tipo:  ThreeVector, LorentzVector, … I dati utente possono essere associati a candidati, ma anche a qualsiasi altri tipo di oggetti (cluster, traccia, etc.) I dettagli tecnologici saranno nascosti quanto più possibile all’utente

Luca Lista - Capri /04/2003 Interfaccia proposta: UsrCandidateBlock B0Data; UsrVariableFloat mES( “mES” ); UsrVariableFloat deltaE( “deltaE” ); for each BtaCandidate * cand { mES =...; deltaE =...; // compute the values B0Data.put( cand, mES ); // put in the micro B0Data.put( cand, deltaE ); } for each BtaCandidate * cand { bool found = B0Data.get( cand, mES ); // get candidate mES from micro found &= B0Data.get( cand, deltaE ); // get candidate deltaE } Inizio del job: Declare variables Scrittura dati (AWG) Lettura dati (Utente)

Luca Lista - Capri /04/2003 Dimensioni attuali dei nuovi Micro Nuovi Micro = Mini ridotti (solo le liste interessanti)  Quntità persistenti = “reco” solo quantità usate dei candidati, niente dati di basso livello Dimensione fisica dei file: 2.5KBytes/event (AllEvents)  Includendo le sovrastrutture di Objy  Senza compressione (ROOT I/O) Kbytes/eventTot.SvtDchTrkDrcEmcIfrPidTrg Mini standard Mini Ridotti Circa la dimensione attuale dei micro!

Luca Lista - Capri /04/2003 Velocità di accesso Ricostruire le liste di candidati standard Accesso a tutti i candidati di tutte le liste  Ricostruire il MicroAdapter per ogni candidato  Momento, energia, … Tempo necessario: 26 msec/event  pentium 800MHz, AllEvents msec/eventoSum Bdb (read + unpack) Emc (trk match) Beta (load) Beta (Quals) Mini Ridotti I CalQual vengono ricalcolati

Luca Lista - Capri /04/2003 Miglioramenti nelle prestazioni Re-implementazione di Beta  La maggior causa delle inefficienze è nella struttura di Beta Inefficiente gestione della memoria e del modello ad oggetti  Il progetto prende il nome di Gamma Jane Tinslay è la coordinatrice del progetto e principale ideatrice  Scopo del progetto: Migliorare l’efficienza di Beta Garantire la compatibilità col codice di analisi esistente Aggiornamento dell’Event-store  Lettura e decodifica sono rimandati quando richiesto La lettura dei dati dal framework sarà efficiente quanto ROOT/Cint Miglioramenti dell’efficienza generali:  Identificare e risolvere problemi nel codice di analisi standard

Luca Lista - Capri /04/2003 Scadenze del progetto Test di aprile  Produrre prototipi per i nuovi Micro per un piccolo sottoinsieme di stream  Supportare solo un sottoinsieme delle nuove possibilità: Candidati compositi Accesso interattivo  Primi riscontri da parte dei fisici 20 marzo:  Conceptual design review di Gamma Test di luglio  Sviluppare il design finale dei nuovi Micro Struttura persistente integrata con i Mini  Supportare tutte (o quasi) le nuove possibilità: Diversi livelli di persistenza per i candidati compositi con diverse informazioni Dati utenti generici persistenti Collegamento di dati tra più file  Ulteriori riscontri da parte degli analisti Ottobre  Prima vera produzione In seguito alla modifica all’event store è anche previsto un aggiornamento delle procedure di Prompt Reconstruction e Simulation Production