Agenda

1. Topics and Tasks                                     — All                
2. Software Roundtable - brief reports         -- All
3. Questions?                                               — All

Topics and Tasks:

•  Monte Carlo and Data don’t agree.
•  Issue with tracking efficiency in data?
•  Differences between MC and data?
•  Generators? 
•  Background?
•  Trident/Möller selection?
•  Geometry, update the accuracy?
•  Code is too slow.
•  Earlier decision to drop event?
•  Optimize the tracking / tracking strategies?
•  Find t0 and amplitude faster for ECal pulse and SVT pulse.
•  Further/other optimizations?

Tasks:

•  Tracking efficiency for data                   — Norman
•  Differences between MC and Data:
•  Trident selection correct & pure?                        — Rafo
•  Sufficient background events included?
•  Add the WAB to the MC in the correct proportion.  — Bradley
•  Möller selection correct & pure?                          — Bradley
•  Create tools to mix pulser data with MC signal — ?
•  Geometry of MC sufficiently close?                      — ?
•  Add SVT dead material to geometry                            — ?
•  Survey & Alignment details in MC model?                 — ?
• Generators                                  – Luca
• Look at code speed and benchmark    — Jeremy
• Code speedup, early event drop          — Matt ?
• Code speedup, tracking                        —  ?
• Code speedup: pulse fit                         — 

Discussion:

ECAL geometry was updated, but this has not been tested yet. The new geometry allows the specification of the front and back face for each crystal individually. The position of the ECAL is determined first by survey results, but finally from the SVT tracks, since we do not have an absolute reference point. The surveys of the SVT are put into the MC model of the SVT, but the detailed changes that come from the alignment do not get inverted and propagated to the MC geometry. This is probably not needed.

The beam rotation and position is adjusted in a step between the generators and SLIC. The code to move the beam is available, but the results from data analysis telling us where the beam is are currently not used to update the simulation.

The z-position of the target is off by about 5 mm, according to Sho's analysis. Should this also go into the MC? How about the slight difference in thickness?

Adding Pulser Data to MC

•  Mix pulser data beam background in with “physics signal” MC.
•  Seems most straight forward way to go.
•  Most accurate way to get the detector noise into the MC.
•  The pulser data will contain a small amount of physics signal as well, probably insignificant amounts.  Could be filtered out at event level.
•  This could possibly help explain discrepancy between MC and data.
•  This does not address the problems of whether the Trident/Möller/WAB etc physics signals are correctly modeled. We still need to put those in.
•  Because the actual data is triggered, it will skew the background events towards more severe ones that cause a trigger. The pulser data will not do this.
•  Strip pulser data of tracks, then mix in with a full MC
•  This will only address the pure random noise and accidentals in the detector. 
•  Still need all the other beam related backgrounds.
•  Much harder to implement.
•  Add the “singles 0” in as well, at some rate?
•  Now it gets complicated…

Discussion:

Should we do this?

To answer the question, we should first look at the pulser data and compare it to a simulated beam background. There was some discussion on how to do this correctly. We don't have the equivalent of pulser data, or a pulser trigger in the MC. It seems that the way to do this would be to take the EGS5 beam background MC, build up 200 ns pulse trains, and call that a pulser trigger. 

Rafo pointed out that for the ECAL you could also use data that is outside of the trigger window. This would help with statistics. It won't really work for the SVT though.