Reconstruction WG Meeting Minutes March 26th, 2024 03:30 - 04:45 PM EDT ================================== Electron-Finder Update (1/2) Tristan Protzman ============================ - Working on implementing comments to EDM4eic PR #52 and EICrecon PR #1277 - EICrecon changes have been implemented locally, and now running quick tests to confirm nothing breaks - Goal is to test and evaluate performance over next few days Discussion ---------- Markus - Great to see progress on this; would be ideal to have this in by the April campaign - Is it possible to get to finish tests and get this in by the April Campaign? Tristan - Yes: testing here means running over ~1k events to make sure nothing crashes - Will push changes if nothing breaks (expcted turnaround is a few hours) Markus - Perfect; want to avoid the situation where we are waiting on tests Rosi - Are these comments the only comments to be taken care of? Tristan - Yes ---------- Rosi - Once these are in (i.e. at least after April campaign), we should talk about what we want to run and what to do next. Derek - Yes: We definitely should talk about this, and Daniel would like to touch on this today Electron-Finder Update (2/2) Daniel Brandenburg ============================ - Main goal is to get PRs in for April campaign - These will implement the initial DIS electron-finder algorithm - Tristan is helping to finalize these PRs - Next Steps: - Integrate tracks into the algorithm - Work towards "truthless" chain, i.e. removing all pieces which rely on truth information - Develop data structures relevent to the electron-finder - Note that there is help from inclusive to work on optimizing track matching Discussion ---------- Tyler - Practical point: the student who was going to help from inclusive may not be able to help on timescales we need - He's currently writing his thesis Daniel - That makes sense: we can keep looking for help - What do we need to do for optimizing track matching? Tyler - Everything is there to do optimization, but there are some points to resolve: - Issue with names in the track matching algoirthm (hadron endcap was affected) - Imaging clusters always have a position of 0 - This will likely be a larger effort to resolve Markus - Once inital algorithm is in place, we can coordinate this with the Reco WG - This meeting will be the ideal place to discuss this topic - One thing we need to do is improve the separation of hadron/ lepton tracks - Another thing the coordinators will do soon is to evaluate the old priority tasks and identify new ones ---------- Rosi - It might be good for analyzers to jump on the April campaign - Conveners could present on how to access data in PWGs - This will get eyeballs on the e-finder output and help continue matriculating people Daniel - Yes, that would be very good: I can help do this at the inclusive meeting this week or the week after Rosi - There will be an analysis meeting this Friday and then 2 weeks from now - Would it make sense to touch on this before or after the campaign? - We also want to make sure everyone sees this, not just the inclusive PWG, - So would it make sense to present on this at the analysis meeting? Markus - We can discuss this at the conveners meeting in order to roll this out in a coordinated manner Rosi - Sounds good: we won't touch on this at this week's analysis meeting Markus - Lets wait until after the campaign to make sure the e-finder gets in Daniel - Could you clarify: is there some concern about the e-finder not making it in for the April campaign? Markus - It should be in: my concerns is that the status nos is similar to how it was in Febraury, so just being cautious Daniel - The issue in February was that there were disagreements and no actionable items - That is not the case now Rosi - To clarify: work is being done, and Markus is just being cautious - Let's focus on what needs to be done now ---------- Shujie - Could we talk about the track data structure at next meeting: it would be good to identify where there is synergy and not duplicate efforts Derek - Absolutely! JANA2 Timeslices Update Nathan Brei ======================= - Status as of January 26th: didn't have timeslices due to outstanding issues --> [Ed.: issues listed in slides] - Status as of now: timeslice prototype is functioning and available on GitHub - Changes made to JANA2: - All sources, processors, and omnifactories can be tagged with an "event level" - e.g. Timeslice, Event, Subevent, etc. - JEventUnfolder splits a timelice into events and can merge input streams - Any thing at a higher event level (e.g. Event) can safely reference data at lower levels (e.g. Timeslice) - JANA now builds a topology across different event levels - Timeslice Topologies: - Different from purely sequential event-based JANA2 - There are 3 levels which JEventUnfolder/JEventFolder connects (1) Timeslices (2) Physics events (3) And subevents - Most of the work goes on b/n the 1st two levels - Working protoype is available on Nathan's GitHub - To-Do: - Creating timeslice files and working out logic for splitting timeslices into pysics events - Need guidance from physics-side - Making an event "key", a generalization of event/run numbers - Small details (none of which are showstoppers) - [Proceeds to give live demonstration] Discussion ---------- Dima - I see that there are frames as input to the example processor, but aren't frames tied to events? Where are the timeslices? Nathan - This is b/c this processor is between the old and new (omni) factory synax - We need the event key to swtich over to the omni interface entirely - Our goal is to switch from a universe where you have accss to JEvent to one where we only have the event key - which will in turn remove the need for all of these different base classes, and the std::shared_ptr floating around... Derek - Is the event key related to the SRO group's "heartbeat" concept? Nathan - Likely not: the key needs to be very general Markus - I would like to further define open tasks/next steps: - Do we need anything from PODIO? Nathan - We should have everything we need - But we do need a more sophisticated check using actual physics workflows Markus - We need to clarify w/ SRO/DAQ group what we mean by "event number" in context on streaming - Currently there is no consensus Nathan - I agree: tell me what meeting to attend Markus - will do - Question for developers/analyzers on physics-side: - How do review and validate this? We need to make sure it's doing what we want it to? Nathan - Argreed: the more I know how people want to use this the better and we want to set realistic expectations Dima - Suggestion: make this into a challenge - We can think about this as a "vertex finder" in 4d where the JEventUnfolder slices & dices the input between different levels - So we can inject events into the beginning/end of an edm4hep file, insert the unfolder into our workflow, and see if it works Nathan - Would this be pedagogical or for validation? Dima - Both: the functionality is there Nathan - I like that idea: we need a test case kind of like the digitization test case Dima - Will there be an official EICrecon release for deployment? Nathan - Yes: but you can pull it now and test it out Markus - We should discuss more how to test/deploy this ---------- Tyler - Looking for feedback: - We currently have an inclusives kinematic data type in EDM4eic - A change we think could be useful would a hadronic final state data type - It could include hadronic energy, angle, and sum of all hadronic energy - It would be calculated once - i.e. there would be ONE entry per event - Then would be reused where needed, and could also be used to cut on in anaysis - Don't need feedback now, but please give us feedback! Brian - Conceuptually: when defining the final state, how would this interplay with the e-finder & DIS e-finder having a ranked list of candidates? - The scattered electron is not a fixed thing... Tyler - In 1st implementation: will use the truth information in same way that exisiting kinematics types use truth information - In practice, it might look like the e-finder in this sense - This is a question we will need to discuss more Markus - This looks good: I would suggest with going with this as-is in order to prompt discussion - Brian has a good point, but we shouldn't impede progress Tyler - I agree Markus - Hadronic Final State or similar is a good name: we want to avoid people thinking of this as SIDIS kinematics Tyler - Agreed: good point Markus - To Brian's point: I'm imagining the e-finder/DIS e-finder as being in terms of probabilities/likelihoods not necessarily a "ranking" Brian - Definitely makes sense: getting this in now is good and necessary to prompt discussion. - I'm thinking of this now so we don't design ourselves into a corner. Markus - Definitely: but good to get in now so people can start playing with it Brian - Maybe consider building in something gesturing towards probabilities Tyler - Definitely