Analysis Tools interface - configuration Wouter Verkerke Wouter Verkerke, NIKHEF 1

Typical workflow of a physics analysis 1) ‘Data reduction’ 2) 'Final processing’ : Data processing loop [ data, various MC samples ] Apply all appropriate final correction factors to objects according to latest prescriptions Calculate derived physics quantities needed for final selection criteria (this range from simple (variants of transverse mass) to very complex (kinematic likelihood fits of objects to e.g. a ttbar decay topology) Apply final analysis cuts Optional calculation of further derived physics quantities that are only valid for object that survive final selection (e.g. concepts that require a minimum number of final state objects that were not necessarily there in every event before the final selection Dumping of histograms and counters 3) 'Statistical analysis’ Aggregate estimated signal and background yields from histogram/counting output of simulation samples in to (template) likelihood models that describes the predicted distributions for a given observable (also need to import all kinds of meta-data here to complete model: cross-section, k-factors, luminosities etc...) Fit / limit setting procedure based Likelihood constructed from (template) likelihood model and observed data With systematic uncertainties – procedure is more elaborate - For each systematic uncertainty do - Data processing loop [ various MC samples ] with one systematic param 'up' - Data processing loop [ various MC samples ] with one systematic param ‘down' Wouter Verkerke, NIKHEF 2

Who writes what tool in analysis workflow Apply all appropriate final correction factors to objects according to latest prescriptions –Tools always originate from CP groups, code will be in analysis [base] release Calculate derived physics quantities needed for final selection criteria(…) –Tools originate either from physics group (e.g. standard calculation of mT2), code will be analysis release [specific to a physics group ] Apply final analysis cuts –3) Tool origin will vary. It can either be - Specific code by analysis author - Generic cut-flow tool [ in base release ] configured by author Optional calculation of further derived physics quantities that are only valid for object that survive final selection –Tools originate either from physics group (e.g. top kinematic fitter) [ code in analysis release] or be specific code to this analysis Dumping of histograms and counters –Tool origin will vary. It can either be - Specific code by analysis author - Generic cut-flow tool [ in base release ] configured by author Wouter Verkerke, NIKHEF 3

Use cases ‘classes of tools’ A) Performance group tools for physics use –Examples: Application of JES/electron/muon calibration, b-tagging scale factors, jet/lepton resolution smearing and efficiency correction tools –Author characteristics: which we can presume that the authors have an 'expert-level' understanding of code, which will deliver code to analyzers through analysis releases. –Release cycle: The release cycle of code is O(weeks), but smaller updates related to updated calibration constants can be expected to be delivered on a shorter time scale. –User configurability: The bulk of the configurable options will be preconfigured by experts and shipped with analysis release, but there is an important subset of parameters with frequent user interaction: those that relate to systematic uncertainty variations: these will need to be varied frequently (almost on a per-job basis) B) Standardized physics analysis tools. –Examples: configuration-driven cut flow implementations, histogram dumpers, –Author characteristics: Expert-level. –Release cycle: Long cycles - once functionality is established –User configurability: Depends on tool functionality, but generally extensive Wouter Verkerke, NIKHEF 4

Use cases ‘classes of tools’ C) Physics group common physics code. –Examples: calculation of mT2, kinematic fit of final selection objects to ttbar topology, identification of specific physics objects in MC decay trees (e.g. truth Higgs boson) –Author characteristics: Experience will vary a bit more here, but I think we can generally assume that the same level of expertise and effort is put in code as is done by performance group –Release cycle: Very long cycles, after initial development. Typical tasks such as mT2 calculation or kinematic fits tend to undergo very few changes over time –User configurability: Typically input collections of physics objects must be configured by analysis users for calculations that take 'final selection' sets of objects as input, for which no default naming convention may exist D) Analysis specific code –Examples: all specific code needed to perform a particular physics analysis –Author characteristics: Highly variable, but a substantial contingent of 'novice' users with limited programming skills. Authors are invariably busy and time-constrained, so a fair degree of 'whatever works quickly' code –Release cycle: Very short. Barring systematic variation runs, code tends to be developed in between every iteration –User configurability: Depends on tool functionality and authors programming style [ you'll find anything from people working with extensive configuration tools to 'everything hardcoded' (which also works as the tool is single-purpose) Wouter Verkerke, NIKHEF 5

Some points for discussion (my personal view) Configuration language –‘Interactive’ configuration by user should be possible in both C++ and python so that analyzer can work only in his language of choice (important for ‘novice programmers’) –Options that are usually not touched as part of configuring job (which are essential ‘prescription’ configurations) can always be python (for simplicity) as the’re usually not touched by user. Configuration ‘documentation’ –The full set of available options should be trivially accessible by the user (e.g. through a ‘tool->dumpProperties() command). This should list all available options, not just those (re)configured. Configuration of multiple tool instances –This is a necessary use case, need some scheme to deal with this. –How strongly intertwined is this with sequencing? Wouter Verkerke, NIKHEF 6