Ties Behnke: EU-LC Simulation and Reconstruction 1 EU-LC Simulation & Reconstruction Full simulation...

25
Ties Behnke: EU-LC Simulation and Reconstruction 1 EU-LC Simulation & Reconstruction Full simulation systems: status report The next steps: where do we go from here The simulation challenge: status report The ECFA LC simulation group: Europe: David Ward, Ties Behnke :http://www-zeuthen.de/linear_coll Ties Behnke, DESY

Transcript of Ties Behnke: EU-LC Simulation and Reconstruction 1 EU-LC Simulation & Reconstruction Full simulation...

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

1

EU-LC Simulation & Reconstruction

Full simulation systems: status report

The next steps: where do we go from here

The simulation challenge: status report

The ECFA LC simulation group: Europe: David Ward, Ties Behnke :http://www-zeuthen.de/linear_collider

Ties Behnke, DESY

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

2

The mission

Coordinate the creation of appropriate simulation tools

Coordinate the creation of appropriate reconstruction tools

Provide a frame for the creation of appropriate analysis tools

The boundary conditions:

System should be long lived Should be lightweight We are not a collaboration: commercial software is difficult (funding) Share across regions as much as possible Little to no personpower available

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

3

The ingredients

GeneratorGenerator SimulatorSimulator ReconstructorReconstructor AnalyserAnalyser

Detector descriptionDetector description

“The data highway” IO (persistency) -- files“The data highway” IO (persistency) -- files

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

4

Full simulation

BRAHMS:GEANT3/ f77 basedTESLA TDR detector updated for recent changesComplete simulation (and reconstruction)

MOKKA:GEANT4/ C++ basedTESLA TDR detector “more or less”No reconstruction framework

BRAHMS is still the most complete package, but

MOKKA is quickly getting there, will soon replace BRAHMS SIM

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

5

The future of the simulator(s)

MOKKA is our main GEANT4 based full simulation environment

GEANT4 based light weight, C++ code geometry via mysql and C++ drivers

Our US collegues are evaluating MOKKA to use it as a base for their GEANT4 simulation environment.

MOKKA developments:

Improve the detector models allow for more flexible system: concept of user plugins Watch closely CERN geometry developments (GDML)

Should look at LCD-G4 – MOKKA and possible synergies / common developments

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

6

The data highway: LCIO

Need definition of a data model:

What is a hitWhat is a trackWhat is a calorimeter clusteretc.

Need a common way to store (“persist”) objects

JAS

ROOT

HBOOK

Objectivity

Anything else?

LCIO: a simple data model with underlying persistency system:

Serial packed files with pointer and “block” support

Event object

Hit objects

“Reconstructed Particles”: Track and cluster objects“Reconstructed quantities” objects

Com

plex

ity

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

7

LCIO: LC persistency framework

JETS

Vertex

HITS

Tracker hits

PARTICLES

Calorimeter Hits

Tracks

Clusters

OBJECTS

MONTE CARLO INFORMATION

SIMULATION RECONSTRUCTION ANALYSIS

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

8

LCIO data model

LCParticle

LCReconstructedParticle LCCompound

pointer pointer

specific extensions

type specificextensions

tracks

cluster

unique, complete

Kshortpion+

pion-

track 17

track 21

cluster 201Kshort2

The data model for reconstructed objects:

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

9

LCIO: Status

Developed in collaboration between SLAC / DESY / LLR (France)

Common data model / persistemcy framework for LC studies

Simple API to store and retrieve data

Same API in C++, Java (and Fortran)Simple underlying IO format (SIO): can be changed easily at a later time

Status:

Development started December 2002 First public pre-release in March First public production release for Montpellier: LCIO 1.0

Full C++ implementationFull Java implementationFull Fortran implementation Hit based data model “fully” defined, reconstructed objetcs still rudimentary

Status:

Development started December 2002 First public pre-release in March First public production release for Montpellier: LCIO 1.0

Full C++ implementationFull Java implementationFull Fortran implementation Hit based data model “fully” defined, reconstructed objetcs still rudimentary

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

10

LCIO Future developments

reconstruction data model

– refine data model as discussed …

– first implementation soon

add convenient methods and tools

– analyzing the MCParticle tree (graph)

● iterators for MCParticles, e.g. all stable/final particles

● analyzing parent/daughter relationships– adding convenience iterators for LCIO types

● simplify complex C++ syntax with dynamic_casts etc.

add possibility to store generic user data

– calibration constants etc.

respond to user requests

proposal by Frank Gaede

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

11

LCIO user extensions I

want to be able to store data not foreseen in LCIO data model– e.g. calibration constants, prototype data

impossible to extend the data model for all users’ needs !

existing LCIntVec and LCFloatVec not very convenient and efficient

still keep LCIO files self contained– i.e. data should be readable without additional software/ user code

user code independent of file format (SIO)

proposal by Frank Gaede

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

12

LCIO user extensions II

allow user classes with some restrictions:– subclasses of LCObject -> store in event collections– properties have to be basic types:

● int, float, double● can be extended to other types and vectors !

– Properties have to be accessible via user class’● data members or

● accessor member functions– Preprocessor macros for C++ and Java static functions for making class

known to LCIO

proposal by Frank Gaede

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

13

LCIO user extensions III

user classes are stored with data description in the LCIO files

data can be read back even if UserClass definition not available to the

program:

– LGenericObject:

– allows access to properties, via:

● names (convenient)

● indices (faster)

unknown collections can be analyzed with LCIO tools/browser

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

14

LCIO user classes, example I

class UserClass : public lcio::LCObject{ LCOBJECTINFO_FRIEND() ;protected: int myInt ; float myFloat ;public: UserClass(int i) : myInt(i) {} float getMyFloat() const; void setMyFloat(float f) ;} ;

#include "UserClass.h"

float UserClass::getMyFloat() const { return myFloat ;}void UserClass::setMyFloat(float f) { myFloat = f; }

// Make class known to LCIOLCOBJECTINFO_DEFINE( UserClass ) ;LCOBJECTINFO_PROPERTY_DIRECT( &UserClass::myInt , "myInt" ) ;LCOBJECTINFO_PROPERTY( &UserClass::getMyFloat, &UserClass::setMyFloat, "myFloat" ) ;LCOBJECTINFO_REGISTER( UserClass, "UserClass" ) ;

proposal by Frank Gaede

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

15

LCIO as online data format

Both TPC and calorimeter groups look at LCIO as online data format:

example: HCAL calorimeter group at DESY/Hamburg

calorimeter prototype: minical

data-MC comparison of energies in minical

First version of “raw data classes” have been defined.

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

16

Example: Calo hit file (online)

Run : 587 - MiniCal:Signature: HCRDHeadSize: 322Versions: 1|1|1|1RunNo: 587Person: sashaBeam: beamEnergy: 5Orientation: SIPM in frontEvents: 4000000Gate: 150StartUt: 1066153487Trigger: |0|5b|1|40|7|0|0|0|4c|fffffff3|ffffffff|ffffffbf|ffffffb8|ffffff8b|4|8|ffffffd0|4e|1|40|53|33|ffffff98|6|53|33|ffffff98|6|ffffffe0|fffffff3|ffffffff|ffffffbf|ffffff88|4d|1|40|ffffffd4|ffffff8f|4|8|ffffffe4|ffffffc8|1a|40|ffffffa0|ffffffa0|1a|40|c|27|9|40|ffffffb6|4|10|40|0|0|0|0|0|10|ffffffa0|0|3|0|0|0|22|0|0|0|ffffffff|ffffffff|ffffffff|ffffffff|0|0|0|0|ffffffb6|1|0|0|ffffffce|0|10|40|ffffffe4|ffffffc8|1a|40|ffffffa0|ffffffa0|1a|40|ffffffa0|ffffffa0|1a|40|NumADC: 9NumTile: 108X: 0Y: 0Top: 1500Bottom: 1500Veto: 0Comment:ADC_IDs: | 4| 5| 7| 8| 10| 11| 13| 14| 16|

Dump of data file:

detector : MiniCal

collection name : MiniCalRawADC

--------------- print out of CalorimeterHit collection ---------------

flag: 0x0 -> LCIO::CHBIT_LONG : 0 LCIO::CHBIT_BARREL : 0 LCIO::CHBIT_ID1 : 0 LCIO::CHBIT_PDG : 0

cellId0(bytes) | cellId1(bytes) | energy/amplitude | position (x,y,z)0: 1/1/15/1 | 15/0/0/0 | -0.0037418 | ( no position avaliable ) |1: 1/2/15/1 | 15/1/0/0 | -0.00508885 | ( no position avaliable ) |2: 1/3/15/1 | 15/2/0/0 | -0.0105953 | ( no position avaliable ) |3: 2/1/15/1 | 15/3/0/0 | -0.0164467 | ( no position avaliable ) |4: 2/2/15/1 | 15/4/0/0 | -0.0418246 | ( no position avaliable ) |5: 2/3/15/1 | 15/5/0/0 | -0.0189564 | ( no position avaliable ) |6: 3/1/15/1 | 15/6/0/0 | -0.0130033 | ( no position avaliable ) |7: 3/2/15/1 | 15/7/0/0 | -0.0447505 | ( no position avaliable ) |8: 3/3/15/1 | 15/8/0/0 | -0.000621088 | ( no position avaliable )

LCIO can be used online

eases access to data and comparison to MC

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

17

Reconstruction

BRAHMS/ f77 based reconstruction:

Complete and sophisticated trackingParticle flow reconstruction packageTools (n-tuple for analysis, interface to main packages like ZVTOP, ...)

OO world:

No coherent reconstruction frame yetLCIO allows using f77 based reconstruction package on MOKKA output

(first version of MOKKA- BRAHMS connection released)

We need to move fast towards a OO based reconstruction framework, to enable reconstruction program developments!

We need to move fast towards a OO based reconstruction framework, to enable reconstruction program developments!

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

18

Reconstruction

BRAHMS: sophisticated and complete reconstruction software availableOO based: no reconstruction tools available at the moment

Status of reconstruction packages:

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

19

Reconstruction

Hits simulated in detector (BRAHMS)

Tracks and Pflowobjects reconstructed(BRAHMS reco)

Plots Karsten Buesser

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

20

The Plan

Develop a plain C++ reconstruction framework

LCIO as data modelPossibly CGA as geometry access modelVery simple interface, no fancy interactive environment for a startMulti language support is no problem (JAVA ...)

Use LCIO ROOT LCIO JAS

to provide a simple user interaction with the reconstruction

At this stage: remain independent of any particular environment (root, JAS, PAW, ...)be open for future developmentsbe light-weight (minimise the number of libraries the user needs to install)

At this stage: remain independent of any particular environment (root, JAS, PAW, ...)be open for future developmentsbe light-weight (minimise the number of libraries the user needs to install)

.... but we are still far from this goal...

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

21

Fast Simulation

SIMDET: fast, parametrised Monte Carlo

NEW: interface to used track based ZVTOP in SIMDET improvements to parametrisations

SGV: fast, semi-parametrised Monte Carlo (produces hits)

NEW: interface to ZVTOP in SGV

At the moment, fast simulations work, are producing physics resultsbutin Europe we have no project for a modern fast simulator

Our US collegues are developing a similar system

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

22

Software: Outlook

Simulation:

Converge towards GEANT4 based MOKKA simulation program should become more flexible and user friendly Close collaboration with our US collegues on simulation establised

IO:

LC specific persistency scheme and data model established Interface to C++, JAVA and Fortran exists Common development with our US collegues

Reconstruction:

Next big project Digitisation and reconstruction “complete” in BRAHMS Much effort needed in OO framework: the next project

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

23

Towards a simulation challenge

Software environment: see previous slides

Access to data:

Need transparent and flexible access system Data volume small compared to LHC, but still significant

The plan:

User interface/ interaction: use the GRID computing model and software

Storage manager: dCache (FNAL and DESY, integrated into GRID)

GLOBUS authentication manager

The challenge: be able at the end of the current ECFA study to do a “blind” analysis challenge (A. Wagner, Amsterdam)

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

24

LC Data depository

Database interface to data stored under dCache at DESY

Current problems: access from outside DESY (being worked on)

Tie

s B

ehn

ke:

EU

-LC

S

imul

atio

n a

nd R

econ

stru

ctio

n

25

Summary

Software tools present a significant challenge

Progress on the simulation: GEANT3 based simulation more stable and completeGEANT4 based simulation becoming availableCommon persistency scheme is reality

Progress on the reconstruction:BRAHMS based reconstruction existsOO reconstruction still in the futureLCIO input existsLCIO output being defined

Goals: GEANT4 based simultorSimple reconstruction environment independent of particular frameworkLCIO as basic data format and model to facilitate data exchangeManagement of data sets through GRID like system