Definizione del DC04 Attivita di simulazione e ricostruzione per il DC04 Stato di Famos Passaggio da...

Definizione del DC04Definizione del DC04Attivita’ di simulazione e ricostruzione per il Attivita’ di simulazione e ricostruzione per il

DC04DC04Stato di FamosStato di Famos

Passaggio da Objectivity a RootPassaggio da Objectivity a Root

Lucia SilvestrisINFN-Bari

Definizione del DC04Definizione del DC04

17 Gennaio 200317 Gennaio 2003 DC04 e stato di FamosDC04 e stato di Famos L. SilvestrisL. Silvestris 3

5%, 25%, DC04…5%, 25%, DC04…

In the LHCC Milestone it is defined as a 5% Challenge– But that is 5% of 1034 running, or 25% of 2x1033 (Startup)– In any case it represents a factor 4 over Spring 2002,

consistent with the goal of doubling complexity each year to reach a full-scale (for LHC startup) test by Spring 2006

– Call it DC04 (And the others DC05, DC06) to get over the % confusion

More importantly, – Previous challenges have mostly been about doing the

Digitization• (With good reason, it is complex)

– This one will concentrate on the reconstruction, data distribution and early analysis phase

• Move the issue of “Analysis Model” out of the classroom and into the spotlight

D. Stickland, CPT annual reviewD. Stickland, CPT annual review


Two Phases: Phase ITwo Phases: Phase I

Phase I: Pre-Challenge (Must be successful)– Large scale simulation (with Geant4) and digitization– Will prepare the samples for the challenge– Will prepare the samples for the Physics TDR work to get fully

underway– Progressive shakedown of tools and centers

• All centers taking part in challenge should participate to pre-challenge

– The Physics TDR and the Challenge depend on successful completion

• Ensure a solid baseline is available, worry less about being on the cutting edge

Pre-challenge will start in Summer (July/August) 2003


Digitization


Two Phases : Phase IITwo Phases : Phase II

Phase II: Challenge (Must be able to fail)

– Reconstruction at “T0”– Distribution to “T1s”

• Subsequent distribution to “T2s”– Assign “streams” and “analyses” to people at T1 and T2

centers• Some will be able to work entirely within one center• Others will require analysis of data at multiple-centers• GRID tools tested for data movement and job migration

– Not a feeding frenzy, but not just “production”. Users engaged.


Reconstruction

L’attivita di simulazione e ricostruzione per il L’attivita di simulazione e ricostruzione per il DC04DC04


OSCAR & DC04OSCAR & DC04

Towards a fully functional program for the DC04

Needs to be ready in Summer 2003 Present OSCAR2 situation

OSCAR2.1.0– Based on the Mantis toolkit/ framework

integration/COBRA7 prerelease available/ full release in 2 weeks– All detectors included– Based on DDD for the geometry (validated)– Not yet all functionality in place PRS groups will have to

provide • SimTrack selection: What information you want to keep• User limits/tracking & production cuts Validation

– SimHits persistent – Using GEANT4 4.1.p01 version


OSCAR & DC04OSCAR & DC04

External Constraints

GEANT4 version 4.1– December GEANT4 version 5.0– January GEANT4 version 5.0+ with ‘cuts per volume’ Presently we have ‘cuts per material’

Full synchronization with ORCA needs ORCA to use the DDD

for the geometry and corresponding sensitive detector scheme Expected by December/January, see below


OSCAR_2 plans (detail)OSCAR_2 plans (detail)

OSCAR_2_0_0_pre1 – Based on COBRA_6_3_1_pre6– Early week 11.11.02

OSCAR 2_0_0– Based on COBRA_6_3_1– Early week 18.11.02

OSCAR 2_1_0_pre1 i.e. COBRA with ROOT– Based on COBRA_7_0_0_pre?– Early week 18.11.02

OSCAR 2_1_0– Based on COBRA_7_0_0 ?– By 13.12.02 ?

OSCAR 2_1_1_pre1– Starting 15.01.03

Aggressive schedulebut necessary

Production set-up testswith OSCAR 2_1_0_pre1

Physics/response validationwith OSCAR 2_1_0

Il Tracker sta lavorando su questa versione..Il Tracker sta lavorando su questa versione..


OSCAR in 2003OSCAR in 2003

Developing OSCAR2.1.0 in 2003 first quarter of 2003

Start of mini-productions to stress-test, validate &– Compare with CMSIM 1.2.5/1.2.6+

Testbeam data (2002 and earlier)– Tracker and HCAL started already, ECAL coming

Full PRS Physics Validation EffortTransition to cuts per region (January/February)Implement present HF shower data base

(January/February?)Detailed magnetic field check (March 2003?)

– Optimize field parametrization, check geometrical correspondance, visualization,XML Ready by March 2003


OSCAR in 2003OSCAR in 2003

Further development before summer 2003 second quarter of 2003

Performance improvement (time/event ~ CMSIM/now ~2x slower)

Include regression tests, control histograms, OVALStore MetadataInteractivity Additional visualization requirements Generator particles, SimTracks, SimHits, Sensitive Detectors, Magnetic Field,… GEANT4 based HF libraryForward Detectors & Final beampipeUsing HepMC for events? Aim for summer 2003


DC04 & ORCADC04 & ORCA

• Identify now what is missing for “baseline”Identify now what is missing for “baseline”

•geometry handlinggeometry handling

•magnetic field & propagationmagnetic field & propagation

•calibration & alignmentcalibration & alignment

•need a list of issues from each subsystemneed a list of issues from each subsystem

–reconstruction algorithmsreconstruction algorithms

–level of details for digitization & reconstructionlevel of details for digitization & reconstruction

• • Uniform interface to similar objectsUniform interface to similar objects

• • Persistency for default physics objects (Mechanism)Persistency for default physics objects (Mechanism)

•persistency for user-defined classespersistency for user-defined classes


ORCA plans end 2002 begin 2003ORCA plans end 2002 begin 2003

Nov/02 • discussion with PRS• ROOTified version ORCA 7.0.0• SIMHIT persistency in COBRA/ProFound

Dec/02 – Jan/03• geometry from DDD operational (RZ kept)• magnetic field from XML and RZ• SIMHIT access uniform among subsystems


ORCA plans 2003ORCA plans 2003

1st quarter 2003• uniform DIGI access• new propagator – no more GEANT3• store misaligned / miscalibrated DIGIs• review with PRS DIGI step fully in place

2nd quarter 2003• dispatching of calibration/alignment events

(mechanism)• calibration database (real or fake) access• digitization at “baseline” software level• update of persistency to baseline technology• persistency of ANALYSIS-OBJECTS (AO)


ORCA ORCA

3rd quarter 2003• update reconstruction algorithms• first version of calibration/alignment jobs• distributed access to AOD• first version of analysis jobs (tasks and code)• creation & distribution of event streams

operational

4th quarter 2003• calibration/alignment jobs ready• review and finalize analysis jobs (tasks, not code)• finalize “baseline” reconstruction algorithms,

event streams• finalize “baseline” AOD

9 January 2004: ORCA READY

Stato di FamosStato di Famos


Structure of FAMOS nowStructure of FAMOS now

COBRA

ORCA

Generatorto Analysis

ORCAInterface

DDD

FamosGeneric

Examples

TTrackBuilder

FATSIM

FTsim

FastMuonLvl1Trigger

G2ATracker

FamosManager

FamosEventReader

ExFATSIM

ExFTSim

FamosGeometryHandler

FastCalorimety

GeneratorToORCA

ExElMatching


Simulation ChainSimulation Chain

MC 4-vector

SimHit

RecHit / Digi

Analysis object

FAMOS/ORCA

ORCA

FAMOS/ORCA

OSCAR

FAMOS/OSCAR Start with fastest modeAIM: 1000 times faster

MC 4-vector

Analysis object

100-200 sec

1-10 sec

10-100 sec


Event handlingEvent handling

working: Stephan Wynhoff, Artur Kalinowski– Use RawHepEvent for communication– FamosEventMgr reads the GeneratorInformation– FamosEventMgr calls the simulation packages in sequence


FamosEventMgrFamosEventMgr

normal COBRA Observero Singleton

accepts registrations of FamosSimulatorsreads RawHepEvent from DB or Pythia6, etc.

o use FakeRecReader to run without DB

gives RawHepEvent to each FamosSimulatoro currently: sequence of registrations

keeps history of RawHepEvent (after each FamosSimulator)

next: provide geometry from DDD


Particle & Material EffectsParticle & Material Effects

working: Dave BaileyWritten

– Multiple Scattering– Pair Production– Bremsstrahlung– dE/dx– Long-lived particle decays

In Progress– Gflash generic classes for ECAL/HCAL shower

simulation


Material EffectsMaterial Effects

Material Effects Classes– All take RawHepEventParticle and

TrajectoryStateOnSurface• For particle ID and momentum propagated to a

surface using magnetic field– Return list (if appropriate) of RawHepEventParticle

daughters and their associate FreeTrajectoryState• To update event record and allow simple

propagation to next surface

Simulation code is re-write of Geant 3 routines– No step lengths– Just use material depth from MaterialProperties of

surfaces encountered during swim through magnetic field up to calorimeter surface.

– Constant magnetic field


Material Effects SimulationMaterial Effects Simulation

Top– Distribution of scattering

angle for multiple scattering of 2 GeV electron

• Angle measured from incident electron direction

Bottom– Energy spectrum of Brems

photons from 28 GeV electron

• Note log scale

Multiple Scattering(2 GeV electron)

0

200

400

600

800

1000

0 0.005 0.01 0.015 0.02 0.025Angle (Radians)

Bremsstrahlung(28 GeV electron)

1

10

100

1000

10000

0 5 10 15Radiated Photon Energy (GeV)


TrackerTracker

working: Marco Battaglia– Tracker response/geometry

• single Tracks• Vertices• Jets

– account for resolutions and correlations– FTSim module

• extrapolate generator particle(s) to innermost detector layer

• build parameterized covariance matrix• get resolutions and smear track parameters• extrapolate back to (0,0,0), compute impact

parameters (+errors)• build RecTracks


FTsimFTsim

Parameterize covariance matrix diagonal elements as function of p and |cos|

Covariance matrix elements: < Cjj >


FTsimFTsim

Parameterized with – bb events– DY events

33 events/sec

or0.03 s/ev


CalorimetryCalorimetry

Simple calorimetric clusters– ECAL – use only electrons & photons

– HCAL, VCAL – use all but muons & neutrinos

– Generate SimpleCaloCluster objects• provides energy, phi, theta, radius,

link to generator particle– Simplified geometry (hard coded frontface numbers)

working: Artur Kalinowski


Single ElectronSingle Electron


Z-mass ReconstructionZ-mass Reconstruction

ORCA

FAMOSPythia

mZ [GeV]

[GeV]

Pythia 91.26 1.9

ORCA 20.44 3.0

FAMOS 91.91 2.4


MuonMuon

• Goal for FastMuon:

• reproduce full simulation results in the large N limit• high performance• fit naturally inside COBRA – ORCA framework• easy to maintain

working: Filip Moortgat


FastMuonFastMuon

FastL1GlobalMuonTrigger

FastL3MuonReconstructorFamosEventMgr

FastMuon

FML1EfficiencyHandler

FML1PtSmearer

• L1 Muon Trigger:

• efficiency parameterized as f (, )• then PT is smeared as f (pT gen, )• then discretized into 5 bit (32 values)• object returned is a simple version of the ORCA L1MuGlobalMuonTrigger (returns 4 GMTcands)

• parameter tuning and comparison with full ORCA ongoing


Single Muon Results (1)Single Muon Results (1)

L1 muon Pt spectrum

Red: ORCABlue: FAMOS

pt [ GeV]


Single Muon Results (2)Single Muon Results (2)

Pt > 20 GeV

90%

pt [ GeV]

L1 turn-on curve

Red: ORCABlue: FAMOS


Muon Level-3Muon Level-3

Read event from FAMOS event managerRun FastMuonLvl1TriggerFor accepted only:

– Run FTSim– match L1MuonCandidate with Track

• Monte-Carlo truth• planned – eta/phi cone (level-2Tk)

– take resolutions from FTsim (to be improved)– (add efficiency for level-3 muons)


H -> 4 muonsH -> 4 muons

mass resolution:ORCA – 1.2 GeVFAMOS – 0.9 GeV


TimingTiming

fraction time/event [msec]

Framework 3% 2

Pythia 40% 25

FTSim 9% 6

FastCalorimetry 34% 22

Muon-Lvl1 5% 3

Muon-Lvl3 9% 6

cmsim + ORCA 312500% 200000

FAMOS is really fast


SummarySummary

– Mini-framework for fast simulation & reconstruction prototype ready (FAMOS_0_6_0)

– First Modules for relevant tasks exist• FATSIM, FTSIM creates reconstructed tracks• MuonLvl1Trigger

– More modules to integrate• Material effects, Conversions, etc.• FastCalorimetry• FastMuon

– DDD integration– GFLASH– fast SimHits, RecHits, all the other options

FAMOS1.0.0

Dec/02

Thanks to Dave Bailey, Marco Battaglia, Artur Kalinowski, Filip Moortgat

Passaggio da Objectivity a ROOTPassaggio da Objectivity a ROOT


The ChangesThe Changes

ORCA_6 – Objectivity/DB– ddl files -> header files, schema file (makeallddl)– database local or remote

• collection of files (.boot and .FDDB to locate them)

ORCA_7– ROOT-IO– data dictionaries (rootcint)– “database” in local directory

• no combined information

Abbiamo chiesto a Stephan di fornire qualche esempio/documentazione che utilizza ROOT

invece di Objectivity


Changes of CodeChanges of Code

ONLY packages with persistent classes affected– Calorimetry

• CaloHit, CaloDataFrame, CaloRecHit, EcalSelectivTowerReadout, EcalTrigPrim, HcalTrigPrim

– CommonDet• PBasicDet, BasicDet

– CommonReco• PersistentTrack

– Muon• MCommonData, MBPersistentSetup, MEPersistentSetup,

MRpcPersistentSetup– Tracker

• CommonStripDet, SiPixelDet, TkPersistentDigi– Trigger

• L1PersistentGlobalTrigger

Fatta dal computing group…Infatti non conosco come funziona un dizionario di ROOT!!!


ORCA_7_0_0_prexx & ORCA_7_1_0ORCA_7_0_0_prexx & ORCA_7_1_0

New configuration (no Objectivity, no HepODBMS)User code identical – compiles & links right awayno more OO_FD_BOOT or BootFile=HIT writing

– run writeHits in the directory for “database”all files are local

– .orcarc unchangedHIT reading

– run in the “database” directory– .orcarc unchanged

no problem without and with pileupreading worksreconstruction of clusters, tracks, muons worksSiamo in good shape, Stephan pensava di poter avere una

versione da distribuire ai laboratori eterni in due settimane..


ProblemiProblemi

• Ci sono un certo numero di problemi che vengono trovati in quanto ROOT non consente di fare alcune cose prima permesse con Objectivity..

• Comunque il ROOT Team risponde in maniera collaborativa..

• Naturalmente ci dobbiamo creare versioni nostre di ROOT… Si e’ chiesto che LCG si prenda in carico questo lavoro di librarian!!


Immediate FutureImmediate Future

ORCA_7_0_0_pre4 has most (all?) problems fixed.ORCA_7 with ROOT-IO works for developmentRelease ORCA_7_0_0 simultaneously to

ORCA_6_3_0

SAME RECONSTRUCTION CODE main development thread is ORCA_7ORCA_6 only for bug-fixes

– parallel ORCA_6 + ORCA_7 possible but painfulonly with good arguments


SummarySummary

Transition from Objectivity/DB -> ROOT-IO very smooth

ROOT-IO is not a databaseTools for file location & access are neededfirst ORCA release for developers in 1-2 weeks

(developers means – it’s a bit tedious)

Thanks to Bill Tanenbaum, Vincenzo Innocenteand the ROOT team

Definizione del DC04 Attivita di simulazione e ricostruzione per il DC04 Stato di Famos Passaggio da...

Documents

Transcript of Definizione del DC04 Attivita di simulazione e ricostruzione per il DC04 Stato di Famos Passaggio da...