Trigger Size in Release 14

This page documents the efforts to reduce the size of the trigger EDM for release 14. Firstly, let me define "trigger EDM" (as used in this page). The size of the trigger content of the AOD is defined by three things:

• type of physics event
• trigger menu used
• size of trigger objects

In this page, the "trigger EDM" is defined as the content (and therefore size) of each trigger object. The number of trigger objects per event is also an important number when considering the size of the trigger content in the AOD - but the goal of this work is to reduce the size of each trigger object - decisions about the trigger menu are not discussed here.

Preliminary Numbers from 14.2.X (with mig6)

The 14.2.X numbers are from 50 event June 13 RTT test ESD file for the top 10 size items:

14.2.X	13.0.40.2	Collection
20.9	38.4	TrigInDetTrackCollection
19.7	26.0	TrackParticleContainer
1.9	14.7	TrigL2BphysContainer
0.1	11.9	TrigDecision
9.1	7.4	HLTResult_EF
5.8	4.4	HLTResult_L2
0	4.0	TrigInDetTrackTruthMap
1.2	3.5	TrigPhotonContainer
2.0	2.6	egDetailContainer
4.7	1.6	CaloClusterContainer
65 kb	115 kb	Sum of Top 10

Total trigger size of the top events with "default" menu is about 75kB/event - a significant improvement from 13.0.40 number of ~140kB/event. Conservatively, I would put a 20kB/event uncertainty on the 75kB/event.

Plans to Reduce Size (from release 13.0.30 benchmark)

Here is a list of the TrigEvent persistent classes and possible ways to save (sizes are top events with 13.0.30 default menu):

Size (kB/evt)	# Objects (407 evts)	Class	Persistent Content	Potential Improvement
0.03	814	TrigMissingET	3 double, 1 long	prec
0.2	2589	TrigT2Jet	6 float, 1 long	prec
0.09	722	TrigMuonEF	1 P4IPtCotThPhiM, 1 string, 1 double, 1 int	prec
0.02	536	MuonFeature	8 float, 2 int	prec
0.2	503	CombinedMuonFeature	1 MuonFeature, 1 TrigInDetTrack, 2 float	links, prec
0.3	6457	TrigL2Bjet	11 float, 1 int, 1 bool	prec
0.3	6457	TrigEFBjet	11 float, 1 int	prec
0.6	277	TrigEFBphys	1 TrigEFBphys, 1 enum, 3 float, 1 int, 1 bool	prec
12	481	TrigL2Bphys	1 TrigL2Bphys, 1 TrigVertex, 1 enum, 4 floats, 1 int	links, prec
16	20827	TrigVertex	1 vector<TrigInDetTrack>, 1 enum, 1 double, 7 float, 2 int	links, prec
0.3	1944	TrigTau	1 P4PtEtaPhiM, 6 float, 2 int	prec
1	2009	TrigTauCluster	1 TrigCaloCluster, 1 float[25], 5 float[4], 4 float[3], 8 float, 1 int	prec
2	3745	TrigElectron	1 P4PtEtaPhiM, 1 enum, 8 float, 3 int, 1 bool	prec
2	5220	TrigPhoton	1 P4PtEtaPhiM, 1 TrigEMCluster, 5 float, 1 int, 1 bool	link, prec
0.7	2144	TrigEMCluster	1 TrigCaloCluster, 1 float[25], 12 float	prec
		TrigCaloCluster	6 floats, 1 long, 1 int	prec
10	407	TrigDecision	2 HLTResult, 1 Lvl1Result, 1 uint32_t	link
4	407	HLTResult_L2	3 vector<uint32_t>	none
6	407	HLTResult_EF	3 vector<uint32_t>	none
0.3	15103	TrigRoiDescriptor	1 vector<uint32_t>, 3 uint, 4 float	prec
0.1	407	Lvl1AODPrescaleConfigData	1 vector<uint32_t>, 1 uint32_t	none
0.6	407	Lvl1AODConfigData	8 vector<string>, 1 uint32_t	none
13	407	HLTAODConfigData	2 vector<string>, 10 vector<uint32_t>, 2 uint32_t	once per file
4	407	TrigInDetTrackTruthMap	no persistent object yet	none yet
43	12100	TrigInDetTrack	2 TrigInDetTrackFitPar*, 1 enum, 1 double, 4 int	prec
		TrigInDetTrackFitPar	1 vector<double>*, 1 enum, 6 double, 5 float	prec

Looking at the table above, the actions that appear to make a significant difference will be:

• optimizing the precision of the TrigInDetTrack and TrigInDetTrackFitPar data members
  • Dmitry Emeliyanov suggests we can drop the 'errors' in the FitParams (build them on the fly from the cov. matrix) and change the cov matrix to floats using a Kalman filter trick he knows.
• remove HLTResult instances from TrigDecision

possible solutions:

1. remove HLTResult in StoreGate when creating TrigDecision (TrigDecisionMaker)
   o  ok for TrigDecision, TrigDecisionTool
   o  BUT re-running of HLT ( ~ TrigSteering/LoopbackConvert ) will fail since
      it's looking for the HLTResult in StoreGate

      We cannot simply change this ~LoopbackConverter class because of
      dependency issues: TrigDecision contains vectors<HLT::Chain> thus depends
      on TrigSteering package. Therefore, we cannot have TrigSteeering package
      also depend on TrigDecision !

2. Change HLTResult inside TrigDecision to a pointer/reference/ElementLink
   o  needs small changes in TrigDecision, TrigDecisionTool ( should be easy)
   o  Re-running ok
   o  Have to keep track of many StoreGate names for TrigDecision, HLTResult
      (particularly after re-running) ... a bit messy ?
   o  Might run into having TrigDecision, but the HLTResult(s) are missing in SG

3. As opotion 1 but
   o  Leave TrigSteering/LoopbackConverter as it is
   o  Add one new package with a simple Athena Algorithm that extracts the
      HLTResults from TrigDecision and puts them into StoreGate
      Needs to be run before L2,EF simulation for re-running only !

• make links in TrigL2Bphys -> TrigVertex -> vector<TrigInDetTrack> chain (can there be a TrigInDetTrackCollection in TrigVertex?)
  • if there are only 480 TrigL2Bphys, but 20000 TrigVertex, who else is making TrigVertex objects, and are they only z information? Looks like TrigIDSCAN.cxx line 822
• HLTAutoConfigData once per file (done)

---

Here are the non- TrigEvent classes:

Size (kB/evt)	# Objects (407 evts)	Class
0.2	407	CTP_Decision
0.4	407	LVL1_ROI
0.7	1928	TauJetContainer
1	3093	egammaContainer
1	1928	TauDetailsContainer
1	3927	CaloClusterContainer
2	3868	egDetailContainer
32	6356	TrackParticleContainer

• Looks like gains in TrackParticleContainer might be useful:
  • Andi Wildauer, claims that gains from double to float are still possible for MeasuredPerigee in TrackParticle. They are on his to-do list, though he needs to be sure they do not loose any necessary precision.

-- AndrewHamilton - 17 Dec 2007