Nuovo Computing Model
L. Lista
Luca Lista - Capri - 10-11/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 - 10-11/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, mES)
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 - 10-11/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 - 10-11/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 - 10-11/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 - 10-11/04/2003
Il nuovo modello di analisi
1.
Identificazione dei campioni di dati da analizzare con strumenti
di bookkeeping
•
2.
Sottomissione (e monitaggio) job di l’analisi
•
•
•
•
3.
4.
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)
Riduzione dei micro-DST per le analisi specifiche
Produzione dei risultati con accesso interattivo ai micro-DST
(ROOT, …)
•
5.
Omogenei per dati e Monte Carlo
Oppure produzione di ntuple ridotte e istogrammi nel formato finale
per l’analisi
Preparazione dei documenti di analisi (BAD)
Luca Lista - Capri - 10-11/04/2003
Dal vecchio al nuovo modello
Skim
prod. centrale
AWG Skim
Ntuple AWG
Ntuple ridotte
Istogrammi
Job AWG
micro ridotti
job analisi:
skim ridotti
+ user data
Istogrammi
Root interattivo
su nuovi micro
Job analisi
Root interattivo
Analysis Document
Analysis Document
prod. centrale
+ cand. compositi
+ user data AWG
Scenari intermedi possibili…
Luca Lista - Capri - 10-11/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: http://www.slac.stanford.edu/BFROOT/www/
Computing/internal/CMWG2/Requirements2.pdf
Luca Lista - Capri - 10-11/04/2003
Nuovi tool di Bookkeeping
Antonio Ceseracciu
Alvise Dorigo
Martino Piemontese
Luca Lista - Capri - 10-11/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 - 10-11/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 - 10-11/04/2003
Integrazione dei diversi componenti
Luca Lista - Capri - 10-11/04/2003
Nuovo modello di Analisi
Mario Bondioli
Guglielmo De Nardo
Luca Lista
Luca Lista - Capri - 10-11/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 - 10-11/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 - 10-11/04/2003
Dati Utente Generici
• Supporto per quantità definite dall’utente da
incorporare nei Micro-DST
• Esempi comuni di variabili per l’analisi:
 E, mES, mD*,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 - 10-11/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
}
Luca Lista - Capri - 10-11/04/2003
Inizio del
job:
Declare
variables
Scrittura dati
(AWG)
Lettura dati
(Utente)
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/event
Tot.
Svt
Dch
Trk
Drc
Emc
Mini standard
7.6 0.4 0.5 2.1 1.6
Mini Ridotti
1.9 0.0 0.0 0.6 0.0
Ifr
Pid
Trg
2.0
0.2 0.3
0.3
0.9
0.1 0.3
0.0
Circa la dimensione attuale dei micro!
Luca Lista - Capri - 10-11/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/evento
Sum
Mini Ridotti
26
Bdb
Emc
Beta
Beta
(read + unpack) (trk match) (load) (Quals)
8
2
I CalQual vengono ricalcolati
Luca Lista - Capri - 10-11/04/2003
3
13
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 - 10-11/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à:
•
•

•
Primi riscontri da parte dei fisici
20 marzo:

•
Conceptual design review di Gamma
Test di luglio

Sviluppare il design finale dei nuovi Micro
•


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

•
Struttura persistente integrata con i Mini
Supportare tutte (o quasi) le nuove possibilità:
•
•
•
•
Candidati compositi
Accesso interattivo
Prima vera produzione
In seguito alla modifica all’event store è anche previsto un aggiornamento delle
procedure di Prompt Reconstruction e Simulation Production
Luca Lista - Capri - 10-11/04/2003