SoLID Ecal Weekly 20230601
From solidwiki
Revision as of 10:53, 21 September 2023 by Tianye (Talk | contribs) (→Update on sim/data comparison)
Contents
Discussion on Cooking with Updated Tracking
- Presentation by Mike: Tracking with new updates
- with updated/latest tracking, which saves the 10 best tracks: the projected position on SC-D based on the 1 best track, for about 20% of events is still outside the SC-D size (in y). For these 20%, the "best 10" tracks are stored. About 10% has a track passing through SC-C but not identified as the best track, while the remaining 10% have no track passing through SC-C.
- GEM x minus EC cluster x (and y) look similar as before.
- efficiency for L/R of GEM still does not look equal. Xinzhan: the mechanism has been implemented for efficiency correction but need careful gain-matching study. Will be busy for the next 3 weeks (FTBF beam test) but can look into this afterwards.
- Discussions:
- how do efficiency and accuracy affect our detector PID study? -- TBD
- would ECal cluster-assisted GEM tracking be useful for SoLID running? Xinzhan: our algorithm is SBS-based, Weizhi's is not the same. So there is little value in using ECal cluster-assisted tracking, especially given our mixed-particle study (ECal cluster works only for electrons).
- Suggestions and To/Do:
- add target information to track choice. Xinzhan: currently using angle cut (based on Ye's simulation) which has some information, but not the same.
- Xinzhan's suggestion: go through 10 tracks, choose track passing through the scintillator/trigger detector and choose track coming from the target. Should increase from 10 to 20 or 50. Mike will look into this and develop something.
Update on Data Analysis
- Report from Spencer: showed data vs. sim for TS3, no trigger cut yet, MIP aligned "by eye".
- Comments:
- MIP peak for shower: width very different (data wider than sim)
- to get better alignment, may need to fit the peak
- add simulation trigger cuts
- look into rate (normalization) of data vs. simulation.
- Report from Darren: started SULI this week
- Suggestions: Discuss with JLab staff on AI/ML, limited results on the current Confusion Matrix may be limited by the algorithm, collect suggestions for what algorithm to use and then try them out.
- if need more simulation (that can't be done by Ye in a straightforward way) is needed, or if there is extra time, can spend time learning how to run simulation.
Update on Cooking
- pulse deconvolution -- Jixie started from Hall A code and adapted it to our decoder. So far it works for 3 pulses for Shower, but not so well for scintillators (pulse shape is not good or consistent if the light yield is low). Alexandre: will be copying the code to NPS: just for calorimeter.
- Hall C has edge-finding at 4ns/64 grid -- Ye will look into it and "grab" the code. Jixie could then implement. (Note: Jixie's peak finding code already has start/max/end time of the peak but this is only using 4ns sampling time)
Update on sim/data comparison
From Ye:
- PS for multi-trigger runs not understood when PS is not zero;data plot
- artifact of simulation, electron drops too fast at higher end, MIP alignment? resolution?? simulation and data comparison
Discussion on LASPD Timing Analysis Plan
- Background:
- SIDIS program requires LASPD timing to be 150 ps or better for TOF
- LASPD detector design: timing resolution is determined by (FM)PMT's drift time/sqrt(Npe) where Npe is light yield. This is one reason we can't use fibers.
- Current plan for LASPD readout is to use FADCs. What sampling rate should we use for FADC readout of LASPD? (We will probably use TDC to double this up regardless but would be good to know if FADC readout itself can reach 150ps)
- LASPD FADC readout timing resolution is determined by: LASPD intrinsic resolution (scintillator, light guide, PMT), and FADC resolution. The FADC timing resolution needs to be << 150ps.
- Our beam test readout is using 4ns FADCs. Timing resolution we extract from beam test data will help to establish our readout design for SoLID.
- Procedure:
- Implement edge-finding code (from Hall C) in our decoder
- Add pulse edge (timing) to output tree -- may need to integrate with our existing peak-finding algorithm. What does the code give us if multiple pulse?
- Plot t_SC-t_LASPD where SC can be any reference scintillator. We expect the resolution to be: SC, LASPD, and FADC resolution added in quadrature. Is the result within expectation?
- If successful, we can extract timing resolution of preshower and Shower, just for fun -- could be useful for PID and background cleaning since timing of all detector signals for a real track should "line up".