Analysis model s in the top physics group

1. 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! Richard Hawkings CAT physics meeting, 3/4/09 Richard Hawkings

2. 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’ Richard Hawkings

3. 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… Richard Hawkings

4. 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: <lepton>+jets, <lepton><lepton> 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 <map> of extra info, egDetails-style object or use UserDataSvc • … best solution(s) not clear yet Richard Hawkings

5. 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 Richard Hawkings

6. 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, pT>15 GeV) and DPD_SINGLEMU (isol.  pT>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 Richard Hawkings

7. 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 Richard Hawkings