Nuovo Computing Model

1
Nuovo Computing Model

• L. Lista

2
Sommario

• Metodi di analisi attuali
• Motivazioni del nuovo modello di calcolo
• Strumenti per il Bookkeeping
• Nuovo modello di analisi
• Stato del progetto

3
Il processo di analisi oggi

• Identificazione dei campioni di dati da
  analizzare
• Dati (skim, ), Monte Carlo
• Sottomissione job di produzione per lanalisi
• 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
• Riduzione delle ntuple per le analisi specifiche
  (anche in più passi)
• Produzione dei risultati con analisi interattiva
  (PAW, ROOT, fit, )
• Preparazione dei documenti di analisi (BAD)

4
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,

5
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à

6
Motivazioni per un nuovo modello

• Estendere il modello di calcolo attuale per
  laumento di luminosità
• Prompt reconstruction
• Ri-processamento
• Produzione Monte Carlo
• Ottimizzare luso delle risorse
• Spazio disco per gli Analysis Working Groups
• Utilizzo CPU
• Manutenzione del codice,
• Adattarsi a metodologie future
• Objectivity ? Root
• Grid,

7
Il nuovo modello di analisi

• Identificazione dei campioni di dati da
  analizzare con strumenti di bookkeeping
• Omogenei per dati e Monte Carlo
• Sottomissione (e monitaggio) job di lanalisi
• Analisi combinatoria (D, D, B-reco, )
• Calcolo delle quantità fisiche
• Scrittura nuovo micro-DST ridotto contenente le
  informazioni per lanalisi 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, )
• Oppure produzione di ntuple ridotte e istogrammi
  nel formato finale per lanalisi
• Preparazione dei documenti di analisi (BAD)

8
Dal vecchio al nuovo modello
Skim
prod. centrale
prod. centrale cand. compositi user data AWG
AWG Skim
Ntuple AWG
Job AWG
job analisiskim ridotti user data
micro ridotti
Ntuple ridotte
Job analisi
Root interattivosu nuovi micro
Istogrammi
Istogrammi
Root interattivo
Analysis Document
Analysis Document
Scenari intermedi possibili
9
Requisiti per il nuovo modello

• Introduzione di nuovi Micro ( Mini ridotti)
• Migliori prestazioni (1kHz), competitive con
  ntuple
• Output configurabile con laggiunta 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 delluso 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
10
Nuovi tool di Bookkeeping

• Antonio Ceseracciu
• Alvise Dorigo
• Martino Piemontese

11
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
  dellutente

12
Obiettivi del nuovo Bookkeeping

• Migliorare linterfaccia 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

13
Integrazione dei diversi componenti
14
Nuovo modello di Analisi

• Mario Bondioli
• Guglielmo De Nardo
• Luca Lista

15
Obiettivi del nuovo modello di Analisi

• Integrare i Mini e i Micro
• Supportare prodotti aggiuntive dellanalisi
  allinterno dei Micro (skims)
• Candidati Compositi
• User Data generici
• Informazioni dellevento e dei singoli candidati
• Fornire supporto per laccesso ai Micro
  attraverso Root/CINT
• Migliorare le prestazioni dellanalisi
  allinterno 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

16
Candidati compositi

• Scrivere il risultati più costosi per il calcolo
• Non è necessario ri-processare lanalisi
  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

17
Dati Utente Generici

• Supporto per quantità definite dallutente da
  incorporare nei Micro-DST
• Esempi comuni di variabili per lanalisi
• ?E, mES, ?mD,D, cos?B,Dl,
• 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 allutente

18
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)
19
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 Ifr Pid Trg
Mini standard 7.6 0.4 0.5 2.1 1.6 2.0 0.2 0.3 0.3
Mini Ridotti 1.9 0.0 0.0 0.6 0.0 0.9 0.1 0.3 0.0
Circa la dimensione attuale dei micro!
20
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 Bdb (read unpack) Emc (trk match) Beta (load) Beta (Quals)
Mini Ridotti 26 8 2 3 13
I CalQual vengono ricalcolati
21
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 lefficienza di Beta
• Garantire la compatibilità col codice di analisi
  esistente
• Aggiornamento dellEvent-store
• Lettura e decodifica sono rimandati quando
  richiesto
• La lettura dei dati dal framework sarà efficiente
  quanto ROOT/Cint
• Miglioramenti dellefficienza generali
• Identificare e risolvere problemi nel codice di
  analisi standard

22
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