1. Level 2 output Recap TrigElectron prototype Size estimate Current questions/problems Trigger decision Conclusions

2. TE TE TE T2Calo Tracking e25i Hypothesis result (from ID SW review) [from LVL1] class TrigElectron { public: TrigElectron(); ... int nrTracks(); TrigTrack* GetTrack(int i); TrigCluster* GetCluster(); RoIdescriptor* GetRoI(); private: RoIdescriptor* m_roi; TrigCluster* m_cluster; std::vector<TrigTrack*> m_trk; }; EMTauRoI RoIdescriptor TrigCluster RoIdescriptor TrigInDetTrack RoIdescriptor [pointer] TrigElectron [to Ev.Filter] “uses” “seeded by” pointer UK e/gamma - RHUL 21 Sep 2005

3. #ifndef TRIG_ELECTRON #define TRIG_ELECTRON #include <vector> #include <iostream> #include <string> #include "DataModel/DataVector.h" #include "CLIDSvc/CLASS_DEF.h" #include "egammaEvent/EMShowerMinimal.h" #include "TrigInDetEvent/TrigInDetTrack.h" class TrigElectron { public: /** constructors: default constructor needed by POOL */ TrigElectron(); // initialized constructor TrigElectron(int roi, double eta, double phi, double zvtx, double pt, EMShowerMinimal* em,TrigInDetTrack* trk); // copy constructor TrigElectron(TrigElectron& te); // accessor methods int roiId() const; double eta() const; double phi() const; double Zvtx() const; double Pt() const; EMShowerMinimal* cluster(); TrigInDetTrack* track(); private: // data members: electron basic variables int m_roiID; double m_eta; double m_phi0; double m_Zvtx; double m_Et; // data members: trigger objects EMShowerMinimal* m_cluster; TrigInDetTrack* m_track; }; CLASS_DEF( TrigElectron , 127789076 , 1 ); #endif // TRIG_ELECTRON Prototype of TrigElectron • What I’ve got so far: need to test it very soon! • Having trouble making Athena do what I want UK e/gamma - RHUL 21 Sep 2005

4. Try to avoid reproducing variables that are passed anyway (track phi should not be in TrigElectron AND in track) • But if track and cluster are not to be passed to EF then you do want to copy it • These variables can be used as a placeholder to avoid future schema evolution: one day we might want to re-calculate electron phi by combining track and cluster phi & errors • Another argument to keep ET and PT in TrigElectron data members would be to use ET/PT of electron at EF • Perhaps other variables that are used in the hipothesis algorithm (which produces the trigElectron) should be kept in TrigElectron (or perhaps these are monitoring issues) • Additional hypothesis debugging information should maybe go into a separate object (pointed to by trigElectron) • Need to add a pointer to the LVL1 RoI • More important to get the mechanism working now than getting the content right UK e/gamma - RHUL 21 Sep 2005

5. TrigElectron size estimate • Space in the ESD/AOD is at a premium. This poses a constraint on objects to be stored. • This should be helped by storing only RoI-contained objects. • Meeting with Ketevi, Simon, Monika, Ricardo last week to investigate possibilities. • Another constraint comes from the bytestream (~2 kBytes/event). • Assume serialization method from Jiri and Simon works, as requirements are very similar. • A TrigInDetTrack has: 2 TrigInDetTrackParameter : 10 doubles + cov_matrix (1 std::vector<double>*) + 5 int + 1 double + std::vector<TrigSiSpacePoint*>* + std::vector<TRT_DriftCircle*>* • Some of these members (all the vectors) can be made transient and so would not be in the AODs. This leaves 21 doubles and 5 int. UK e/gamma - RHUL 21 Sep 2005

6. New proposal from Xin, Denis, Carlos Presented last week at LArg week Under discussion Assuming a TrigEMCluster is the same size as an EMShowerMinimal it would be ~44 doubles and 2 long ints plus an ElementLink to a CaloCluster - let's say 50 doubles in total. The proposal for the new TrigEMCluster is around 21 doubles and 8 ints: under discussion. This leaves from ~42 doubles + 12 ints to 70 doubles + 5 ints. If a double is 8 bytes and an int and a pointer are 4 bytes this makes a total size ofTrigElectronfrom 392 to 748 bytes. The canonical number is (I think) between 1 and 2 RoIs per event, i.e. ~800 Bytes - 1.4 kBytes/event in AODs TrigTaus, for example, would need up to three tracks; TrigJets might need more tracks or have a "number of tracks in cone" variable, etc.. Only basic electron properties need be stored in bytestream (mask out track & cluster), i.e. basically a few tens of bytes per event EMShowerMinimal/New calo trigger EDM UK e/gamma - RHUL 21 Sep 2005

7. Current questions/problems • Package structure – current solution: • TrigParticle to contain LVL2 output classes and provide POOL converters Trigger/TrigEvent/TrigParticle/ • LVL2 output classes have basic object characteristics as data members plus pointers to constituent objects Trigger/TrigEvent/TrigParticle/TrigElectron Trigger/TrigEvent/TrigParticle/Tau Trigger/TrigEvent/TrigParticle/TrigJet • Persistified TrigInDetTrackCollection but also need to persistify TrigInDetTrack… problems? • Same goes for EMShowerMinimal • Trying to test TrigElectron but running into problems • Not able to produce LVL2 tracks with current recipes (?!) • Need time! Must have something in nightlies for rel.11.0.0 UK e/gamma - RHUL 21 Sep 2005

8. Trigger decision Time looking short to do anything on this for rel.11.0.0 • This applies equally well to LVL1, LVL2 and EF • Trigger decision: • Menu table to be stored in RunStore (may not be feasible yet) • Trigger masks to be stored for each event (interpreted through menu table) • Methods should be provided to interpret masks for each event • Short-term solution (for Rome data) would be to write methods that mimic this for the few signatures which were implemented • Long-term solution: menu table will be in conditions DB as it is part of the trigger configuration • bool IsDefined(“e25i”) • bool IsPassed(“e25i”) • bool TriggerPassed(“EF”) Event mask MenuTable Event mask AOD Event mask UK e/gamma - RHUL 21 Sep 2005

9. Conclusions & outlook • If persistance and serialization mechanism tests are positive, TrigElectron/Tau/Jet would be a good solution for AOD/ESD and for LVL2->EF communication • Space looks small enough for AOD and can be reduced further for bytestream • Need to do basic tests on prototype very soon to be able to include in rel.11.0.0 next week • Is it worth it to include TrigElectron without pointers to track/shower? • Trigger decision : time too short for 11.0.0: should a placeholder be there? UK e/gamma - RHUL 21 Sep 2005

10. Support slides UK e/gamma - RHUL 21 Sep 2005

11. Design : constraints (from ID SW review) • To make persistency/serialization easier avoid: • ElementLinks • Inheritance • Classes should be small and simple: • Maintainable and robust (minimise dependencies) • Size must be minimal to avoid problems for online running • Data objects would be persistified (cluster / RoIdescriptor / Spacepoints?) • This assumes small numbers of objects stored for normal running but potential to store more information for debugging and efficiency studies • “Hypothesis” classes (e.g. “TrigElectron”) should have pointers to tracks, LAr cluster, RoIdescriptor • This avoids duplication of data objects and problems from ElementLinks • This could be redesigned when navigation information is available and persistent/serializeable (being re-designed) • Mainly e/gamma and tau objects currently being defined: probably equal needs for other triggers UK e/gamma - RHUL 21 Sep 2005

12. Design : constraints (from ID SW review) • Persistency - usual recipes from: https://uimon.cern.ch/twiki/bin/view/Atlas/WriteReadDataViaPool • To persistify pointers: • Classes should have virtual destructor (guarantee polymorphism) • Default constructor should initialize all data members especially pointers • No pointers to STL collections (not polymorphic; must be contained by value) • Tested in simple (standalone) case and works “out of the box” • To persistify classes (the usual thing): • Classes must have dictionary fillers: lcgdict pattern • Automatic converters must be generated: poolcnv pattern • To serialize classes (Jiri Masik, LVL2): • Classes must have dictionary fillers as for persistency • Classes should contain only data members of type int, float and pointers to other classes • Has been demonstrated; should investigate serialisation of STL containers UK e/gamma - RHUL 21 Sep 2005

13. Conclusions and outlook • Design should proceed with online running in mind as well as trigger signature development, debugging, etc • It seems a good idea to minimise complexity and dependencies to improve maintainability and ease persistency/serialisation • Classes to be serialised need to be simple • Ideally store same classes that are used in trigger hypotheses • What could be stored in POOL for algorithm development ? • This is very important and would mean faster development and improved algorithms • But it must be balanced against how much we can store • ESD? New, lighter data structure just for this? • Prototype “hypothesis” classes could be done soon • Same subjects also under discussion in muon community : common solutions should be explored whenever possible • New ESD/AOD classes should be available and validated in release 11 to allow time for redesign UK e/gamma - RHUL 21 Sep 2005