1. 3rd April 2009 1Richard Hawkings Analysis models in the top physics group  A few remarks …  What people are doing now  Where we are going - Top reconstruction framework  Input and output formats  General remarks  N.B. Not official top group ‘policy’ - personal thoughts  … from someone who was not particularly happy with the AMF report! CAT physics meeting, 3/4/09

2. 3rd April 2009 2Richard Hawkings Creative anarchy  March 2009 poll initiated by Nabil Ghodbane  Categories not discussed in advance, and not exclusive … 116 responses  ‘Traditional methods’ dominate (direct AOD analysis, making private ntuples)  SingleTop group D2PD/ntuple also popular (not only with single top group)  Dump of selected AOD object info, plus overlap removal and selection  Some use of ARA and TopPhysD3PD (successor to TopView ntuples)  Less than 50% use a ‘centrally-produced’ DnPD, rest are more ‘hands on’ Private ntuple(=D3PD) analysis with ROOT6657% AOD-based analysis with Athena4741% SingleTopDPDMaker (D2PD/D3PD)2219% AOD or private D2PD with ARA1916% TopPhysD3PDMaker ntuples1816% AtlasModularAnalysis (AMA)1311% EventView-based private package109% ARATopQuarkAnalysis (Athena/ARA dedicated pkg)22%

3. 3rd April 2009 3Richard Hawkings Common top reconstruction code / framework  Some negative aspects of the ‘creative anarchy’  Very difficult to implement, change and cross-check common object selections  Very difficult for groups to work together / validate each other’s work  Same mistakes (e.g. in truth analysis) are made again and again  Moving forward with common top reconstruction code (from TopReco group)  A pseudo-physics subgroup to provide common forum/tools/code/selections for all ATLAS top analyses - unique in the physics groups  TopInputs infrastructure - now ready (see AtlasProtected/TopInputs wiki)  Provide common object selections and overlap removal tools  Using ISelector interfaces ‘approved’ by PAT but largely being implemented by TopReco  Implementing CSC-style selections, updated to rel 14/15, as default  Instead of iterating over ElectronContainer, iterate over TopInput electrons  A bool method gives Use? Yes/No information  Link to more detailed overlap ‘reasoning’ information coming later  TopInputs has persistency - can be added to DPD files  Expect this object selection to be used by all top physics analyses  None of this is top group specific - hope it can migrate to PAT…

4. 3rd April 2009 4Richard Hawkings Common top reconstruction code continued  TopEDM objects have been defined  Classes to represent reconstructed top and ttbar final states  Basically collections of ElementLinks to the constituents of the reconstructed object  Minimal additional functionality - don’t want to define things that don’t always make sense (e.g reconstructed mass of leptonic top quark decay)  Template-based approach: +jets, etc  Classes have persistency so can be added to DPD files  Top reconstruction algorithms are being collected/implemented in framework  E.g. ‘commissioning’ algorithm (3-jet hadronic), tt-bar likelihood and chisq fitters  These start with TopInputs and produce TopEDM objects (in containers)  ‘Decoration’ of TopEDM objects by specific reconstruction algorithms  E.g. adding masses, chisq, fit probabilities etc  Proposal is to make new classes deriving from TopEDM classes and adding information (e.g. TopElectronJetsChisq) … but the persistency is tricky  Alternatives: add of extra info, egDetails-style object or use UserDataSvc  … best solution(s) not clear yet

5. 3rd April 2009 5Richard Hawkings DnPDs in this model  TopInputs and TopEDM have POOL persistency  Can write D{1,2}PDs with input objects of interest (Electrons, Jets etc) + information on top object selection and reconstruction  Resulting DPDs could be analysed in Athena or ARA  Clear need also for ntuples (D3PDs) to look at the output in ROOT  + Easier for newcomers, faster to read, more intuitive  - The disadvantages of leaving the ‘framework’  Need a way to write ntuples for input objects - various possibilities  AMA (Max Bakk already wrote AMA interface for some TopEDM objects)  SingleTopDPDMaker, EWPA or EventView  … all have modules for writing e.g. an Electron (or subset of info) to ROOT ntuple, either directly or via some intermediate transient model  Should be trivial to extend them to TopInput and TopEDM objects  … it would be desirable to have ONE officially supported way of doing this

6. 3rd April 2009 6Richard Hawkings Input formats for top reconstruction  Top reconstruction code runs in Athena …  Can use any format where appropriate SG containers are available (e, mu, jet etc)  ESD, AOD, some performance DPDs which have appropriate selection  DPD_SINGLEEL (medium e, p T >15 GeV) and DPD_SINGLEMU (isol.  p T >20 GeV)  Top is a physics WG, not a performance WG  In principle, should be working from ‘standard’ objects on AOD provided by combined performance groups, no need for ESD access  But … perhaps not true in the beginning  E.g. not all potentially-interesting jet calibrations/algorithms available on AOD  E.g. may want more detailed lepton information when studying lepton efi Z  top  Performance DPDs may offer a good solution for this  Top event volumes are modest, once we understand selection basics  E.g. lepton+  4 jet selection is ~50k events in 100 pb -1  Good potential for using the TAG database and making e.g. AOD skim  Provided TAG variables correspond to the jet/lepton definitions we actually use  TopMixing sample being made available in TAGs db - first real ‘physics driven’ test

7. 3rd April 2009 7Richard Hawkings Final remarks  Working towards more commonality in the top group  Common inputs and reconstruction code - Athena based  Common DnPDs, potentially POOL and ROOT-ntuple format  Tool for producing the latter is not clear yet…  Common analysis code yet to be tackled, but needed e.g. for initial top x-sec  … Easier to achieve commonality across all groups in an analysis (10-20 groups in case of top cross-section) than across all analyses going on at CERN  … Maybe less true in case of combined performance work  Gratuitous remarks  ARA is good for validation - looking at the contents of ESD/AODs etc  Personally not convinced it is a viable analysis framework, esp. for less-experienced  Already imposing ‘requirements’ on EDM; will end up re-inventing Athena - use Athena!  Lots of focus on O(10) data volume reduction: DPD streams;, 100k  10k/event  In the case of top, final analysis will be done with much smaller samples  … Keep flexibility - AOD skims, dropping containers and objects, …  But hard to define this now until we start getting to grips with the real data