CMSSW Tutorial Part 1

Transcription

1 CMSSW Tutorial Part 1 Thiago Tomei

2 Goals of Part 1 Understand the Framework concept. Understand the (modular) architecture. Five types of modules. Understand how modules interact among themselves They interact through the Event. Understand the Event concept.

3 Understand the Framework concept As we have seen: Software bus model One main executable: cmsrun Plugin modules user code is one of them! Config file _cfg.py configures cmsrun execution at runtime.

4 Modular architecture A module is a piece of CMSSW code that can be plugged into the CMSSW executable cmsrun. When preparing an analysis job: The user defines a process. The user attaches modules to that process. Specifies a ParameterSet for each via the _cfg.py file. The process is run for every event, in the order given by the cms.path statement in the _cfg.py, by cmsrun. Five types of modules: Source (not quite a module, but...) EDProducer EDFilter EDAnalyzer OutputModule Advanced: a module is an instantiation of a C++ class, i.e. an object.

5 Modular architecture (2) Modules don't interact directly among themselves. The Event acts as broker among the different modules. Example: module A produces muons, module B needs muons (to make an invariant mass perhaps...) Module A produces muons and puts them into the Event. Module B asks the Event for the muons and uses them. As the user, you define a process in which you will run modules A and B. Then, you define the order in which they will run, and if there are dependencies among them. In the example above, you better make sure that module A runs before module B, because B depends on A. cmsrun automatically runs an ''event loop'', running your process (modules A and B) over all the events.

6 Module Syntax In the _cfg.py file: process.demo = cms.edanalyzer(''demoanalyzer'', mintracks = cms.untracked.uint32(4) ) module label (also called tag) module name module parameters When you label a module, you make no references to its name in the code anymore.

7 A quick example import FWCore.ParameterSet.Config as cms process = cms.process("nobel") Advanced: the configuration language is simply Python! process.themuons = cms.edproducer(''muonproducer'') process.zcandidates = cms.edproducer(''candviewcombiner'', ) decay = cms.string(''themuons@+ themuons@-''), cut = cms.string(''86.0 < mass < 96.0'') process.nobelprize = cms.edanalyzer(''higgsanalysis'', ) children = cms.inputtag(''zcandidates'') process.p = cms.path(process.themuons * process.zcandidates * process.nobelprize) Remember: - module label - module name - parameters

8 Event Data Model In software terms: an Event is a single entity in memory, a C++ type-safe container called The Event contains the minimum well-defined set of data for instance, a single MC hard interaction or a single triggered bunch crossing. Data within the Event are identified by four quantities: C++ class type of the data module label product instance label (usually empty string) process name edm::event reco::muoncollection_themuons NOBEL class type module label process name

9 Getting data from the Event To hold an access result, all Event data access methods use edm::handle<type> where type is the C++ type of the datum. To request data from an Event, use a form of the following: get which either returns one object or throws a C++ exception. getmany which returns a list of zero or more matches to the data request. After get or getmany, indicate how to identify the data, e.g getbylabel, and then use the name associated with the handle type.

10 Another quick example In a source code file: void DemoAnalyzer::analyze(edm::Event const& ievent, edm::eventsetup const& isetup) { edm::handle<reco::trackcollection> trackshandle; ievent.getbylabel(''goodtracks'', trackshandle); // Do some (hopefully) useful analysis here } Analysis modules are usually written as a C++ class inheriting from EDAnalyzer Such a class must have three methods: beginjob(const edm::eventsetup&); analyze(const edm::event&, const edm::eventsetup&); endjob();

11 Ready-to-go modules Many modules are already written. Example consider the beginning of the Z + 2 jets analysis: Reconstruct muons Reconstruct jets Quality and kinematics cuts in the muons Quality and kinematics cuts in the jets At least two muons At least two jets Get the two highest pt muons Invariant mass of the two muons in the Z window Get the two highest Et jets Fill some basic kinematics histogram in a per-event basis

12 Ready-to-go modules Many modules are already written. Example consider the beginning of the Z + 2 jets analysis: globalmuons (already in the standard RECO) siscone5calojets (already in the standard RECO) PtMinMuonSelector EtMinCaloJetSelector MuonCountFilter CaloJetCountFilter LargestPtCandViewSelector CandViewCombiner LargestEtCaloJetSelector CandViewHistoAnalyzer So you would just write a _cfg.py no C++ coding needed at first stage!