Reconstruction WG Meeting Minutes May 14th, 2024 03:30 - 04:45 PM EDT ================================= Introduction Shujie Li, Derek Anderson ========================= - Today is a "special" meeting: focus is on FF reconstruction. Discussion will happen in 2 parts, since not everyone could make today (and this isnt a good slot for Asian collaborators) - Today is part 1: focus on RP/OMD and ZDC - Part 2 will happen in another meeting: the S&C meeting might be a better venue since it would be nicer for Asia timezones. Verbal Update on Calo Reco TDR Progress Derek Anderson ======================================= - Track-based merge-splitting algorithm is ready for review and more comprehensive testing! Please check it out at: https://github.com/eic/EICrecon/pull/1406 Discussion ---------- Miguel - What does this algorithm do? Derek - Based on track projections to a calorimeter, it merges clusters together. Algorithm is inspired by the ATLAS particle flow algorithm. Miguel - And what's the condition for merging? Derek - It calculates a significance between the actual energy of the cluster vs. the expected deposited energy of the track (derived from single particle simulations) - Then if that significance is above a user-configurable threshold, it merges clusters within a delta-r window. Garth - Since this is based on track projections, is this for only charged particles? Derek - That's correct: anything not merged by the track comparison will just be handed off unaltered. - Peter is looking into a calorimeter-only version of the algorithm which would also work for neutral ---------- Shujie - I contacted Chao and Elke to discuss calorimeter reconstruction with background. Meeting will occur next week. - Still need to get algorithms in place for timeframe-based reconstruction. Should we have a meeting during the S&C meeting to discuss since Nathan won't be available next week. Markus - We can parallelize a lot of the work. For example. what you can do is just unfold for a 2 ms time slice and check if tracking is working using the prototype. Kolja - That's what Ben's been working on. There are some technical challenges for merging timeslice files, but can be overcome. Markus - Good. So those checks can proceed while we wait on full timeslice integration into EICrecon. Does this sound like a good plan, Shujie? Shujie - Yes FF System Overview Alex Jentsch ================== - FF detectors - B0: Zvi Citron will give update at upcoming meeting. Sits inside the B0pf magnet (closest to central detector) - OMD: 2 trackers sitting just after the B1apf magnet --> For lower rigidity protons that get past the B0 --> Important for measurements w/ nuclear breakup - RP: sits just before the ZDC and B2pf --> Ditto. - ZDC: Crystal EMCal + SiPM-on-tile HCal. Sits right before the B2pf magnet. --> For reconstructing neutral particles --> Needs both EMCal + HCal b/c processes can produce hard photons AND neutrons - What lights up is *very* dependent on the physics process, not every detector will be hit every time. - Slide 14: white hole in middle plots are 10 sigma cuts, i.e. the "no-go" regions where you get dangerously close to the beam - Have calculated this for several different beam energies - Big challenge is to design FF systems in such a way that we can adequately cover the high and low t regions. Both of which are necessary for the imaging program - Reco Status Overview: - RP/OMD: matrix, and ML reco need knowledge of magnetic field. Particles hit detectors while *not* in a magnetic field, so standard tracking algo.s don't work. - B0: tracking layers are in non-uniform magnetic field, so can use ACTS - ZDC and B0 Crysal EMCal: still working out design - ZDC HCal: non-compensating imaging HCal Discussion ---------- Markus - DD4hep is not the only part of the ePIC simulation, so I recommend to use "ePIC simulation" or "ePIC software" when talking about these aspects ---------- Shujie - Talks like this are very helpful. Should we record this? Derek - ISU doesn't pay for Zoom Pro for its post-docs, and this meeting was made by Marzia, so I don't have recording permissions. - We'll get this worked out by the next meeting. Suggestions from Audience: - We can ping Marzia now (she might not see before meeting is done) - Host labs can make meetings, and then ownership might be able to be transferred - Make sure we're taking minutes (which we are!) RP/OMD Reco Status Alex Jentsch ================== - In general you have a matrix based on the magnetic fields around the detector which describe the trajectory of a proton through detector - Just need to invert this matrix to get the proton momentum from observed hits - 3 approaches: (1) Static: use a single matrix (currently done in EICrecon) --> Works for small angles, and small momentum loss wrt beam (2) Dynamic: calculate matrix for a range of possible momenta and fit result as function of detector hits --> Was tricky to get into EICrecon earlier, and then received funding to study AI/ML approach (3) AI/ML: uses a GNN to do reconstruction ---------- Miguel - Do you have a PR for the AI/ML algorithm? I'm curious about how the GNN is fit? Alex - Not yet, but Sakib will have that in a couple weeks Miguel - Is it just hits? Or does it also include neigbors? Alex - Just hits Miguel - I see. Neighbors are tricky to work in, but would be very useful. ---------- - Dynamic matrix approach: (1) start w/ "input tuning cards" w/ trajectories. Tuned using BMAD simulations (2) Tuning cards get processed by GEANT, and then matrices calculated based on RP hits. Also produces offsets on orbits. (3) Finally, fit the 36 matrix values (+4 offsets) with 2nd order Polynomial as function of momentum fraction xL - Note: need LUT, the chromaticity, to get xL given the hit coordinates - Why do you need a dynamic approach? - You get very large smearing as you drop in pT due to assumptions breaking down - But because of the strong magnetic fields as you exit the detector, thin lens optics assumptions begin to break down and you see large smearing at high pT ---------- Shujie - So how costly is the matrix inversion currently in EICrecon? Are there ways to improve it? Alex - Row-reduction and matrix inverstion is done by hand. It looks hefty, but runs fast b/c it's just some for loops - Naturally, performance of calculation depends on matrix inversion software used ---------- - Why do you need an ML approach? - Because of the strong magnetic fields as you exit the detector, thin lens optics assumptions begin to break down and you see large smearing at high pT - David Ruth and Sakib Rahman now working on ML approach. Work slowed down briefly while Sakib transitioned to BNL. - ML approach in general does better than dynamic matrix, esp. at high pT - Except at very low pT where more smearing was seen than in the dynamic approach - This is not understood yet, but it's also below what we'll likely measure - Status of EICrecon integration: - Model trained with PyTorch outside of EICrecon - Will use ORT to do inference w/ model during algorithm. Sakib is working on implementing this. - Anaysis notes: - One collection for each detector (e.g. ForwardRomanPotRecParticles) - Momenta stored in (x, y, z) components (as per convention) - Truth associations not there, but can be added - Handling the x-ing angle is non-trivial, but David and Brian have been working on tools for users to account for this - Takeaways: - Static method works okay for many cases. Will udpate to dynamic method in future. - ML appraoch currently being integrated. - Want a "1st principles" appraoch and a ML method, so we can understand the ML approach - That's imporant for understanding possible systematics Discussion ---------- Shujie - So what do you currently need in terms of EICrecon and support? Alex - All of these methods need knowledge of the beam momentum, but handing this information down through EICrecon is tricky - Current hack is to read it out of MCParticles, but it would be better if it was metadata in the event header (this is a big task though) - Also could use help streamlining code (e.g. moving manual calculations to dedicated functions) - Also could use knowledge from tracking experts about how to better use Simon - So is clusters of hits? Or is it just hits? Alex - Just hits Simon - So you'll need charge sharing before we can do hit clustering Alex - Charge sharing hasn't been a concern for us so far, and we just need to a straight-line fit between layers Simon - The Low-Q2 tagger does this, so we might be able to make use of that algorithm Alex - Sounds good. Lets meet offline to discuss. Markus - We are currently working through TDR tasks. But afterwards, we want to work towards "holistic" reconstruction that combines the FF and central detectors. Do you have some ideas on this? Alex - Hard to imagine an object that would combine both central and FF info since it strongly depends on the analysis, e.g DVCS - Example: STAR provides detector subsytem info, but things like tracks naturally includes hits from multiple subsystems. But for the FF you don't usually have objects that hit both the central and FF detectors... - You may have some useful objects were multiple hits were observed in multiple FF systems, e.g. vetoing ---------- Shujie - I propose we move the ZDC discussion to next week given the time Sebouh - Sounds good AOB ==== -- no items --