Reconstruction WG Meeting Minutes January 6th, 2025 11:00 AM - 12:30 PM EST6 ================================== Introduction Shujie Li, Derek Anderson ========================= Shujie - Announcements - CM appraoching: there will be some workfests of relevance to reco WG - eg. there will be a PF session during the Jet/HF workfest coordinated by Derek ---------- Derek - Will be an open-discussion session focused on PF wrt. to jet reconstruction and later stages of reconstruction - Agenda will be here https://agenda.infn.it/event/43344/sessions/31920/#20250121 ---------- - There will be an ACTS worfest focused on propagation into PID detectors on Thursday https://agenda.infn.it/event/43344/sessions/32016/#20250123 Discussion ---------- Markus - Any contact from Thomas or Umberto on PID workfest? - We want to make sure PID software connects to software broadly Shujie - Not yet, but there is definitely a PID workfest ---------- Update - We have been contacted, and draft agenda is avaible on indico https://agenda.infn.it/event/43344/sessions/31812/#20250124 ---------- John - Also haven't heard much, will talk with Thomas while at BNL - They want to use this as "a meeting of meetings" Markus - There will also be an AI/ML tutorial at the CM https://agenda.infn.it/event/43344/sessions/31806/#20250123 - And a workfest on epic data: discussion focused on readout to analysis discussion https://agenda.infn.it/event/43344/sessions/31801/#20250121 Derek - Next reco meeting on 20th: everyone okay with skipping? Markus - Naturally, but should have a meeting on the Monday after CM to discuss priorities - Lots for 2025 will be in reco or interplay - Could do 2 meetings in a row Derek - Makes sense: we'll touch base with Dima to coordinate slots with validation group Status of dRICH Reconstruction (continued) Chandra Chatterjee ========================================== - No slides, see slides in previous meeting: https://indico.bnl.gov/event/25539/ - Approaching final design for dRICH, some geometrical aspects under consideration - eg. whether or not to split the dRICH into multiple sectors - Standalone reconstruction is quite trusted, though - Built on optical techniques, Robert(?) from Duke also looking into AI/ML techniques - But exisiting reco makes multiple hadron studies very tricky - pfRICH IRT 2 algorith, DOES handle multi particle topologies well - Now starting on porting IRT 2 into EICrecon - Alexander K. is leading development - The idea is to mock up a fake RICH in dd4hep and start implementing - From a previous email exchange: - Alex's perspective: IRT 2 is NOT final algorithm, actual data reconstruction will be much more elaborate - But getting preliminary tunes/ideas is very important, and we want something "intuitive" to start with - e.g. we want to be able to compare test beam data vs. simulation for dRICH - Only thing for a 1-to-1 comparison is that there is A software algorithm to run in the same environment as both simulation and test beam - Goal is to get to there, but there is not much there right now - Hope is to have a clearer picture after the CM workfest Discussion ---------- Markus - Your overview of exisiting dRICH reco back in December was interesting - It's all in the eic software stack, so that's fanatastic and perfect for reproducibility/collaboration - And for test beam/prototype studies, IRT 1 should serve well since you'll only have single particles - But we do have a deficit in PID reco: we pointed this out in the Argonne CM last year, and there hasn't been progress since - We need something that can handle realistic event topologies - This is an issue (only single particle studies) with the current draft of the pTDR - So we need to prioritize this - We need 3 things to proceed with IRT 2 (a) Validation that IRT 2 is an effective baseline for realistic topologies - We should consider how upcoming experiments at FIA(?) are approaching this - There could be algorithms from there that could also serve as baselines (a) A plan for getting it into EICrecon, and (b) A way to break the pattern of parallel development so it doesn't take a long time to port things back into EICrecon - So what is your perspective on these points? Chandra - IRT 2 has been tested and proven to handle complex topologies (in a standalone way) - n.b. the dRICH rings will be easier to handle than the pfRICH - SO if IRT 2 works for pfRICH, it will work for dRICH - Previously, had issues with geometry in ATHENA (juggler) times - There was a challenge getting the reco to see the same geometry as was done in the standalone tests - Then, they had to make a standalone geometry file. What was the issue, Wouter? Wouter - It was an unwillingness to work in a common software stack. There are no technial issues Chandra - I see. But Chris has recently demonstrated that indeed you can convert the geometry for the dRICH, so shouldn't be an issue for the pfRICH - Challenge IMO is that we have multiple photon paths to consider - We want to confirm that the results are in fact actually MEANINGFUL for realistic events - Alexander is currently working on this cross- check between standalone and official geometries - Once he pushes any fixes to Github, I'll begin working on the dRICH side - Does this answer your question, Markus? Markus - I'm not sure... So we agreed on dd4hep so we can have a common way of specifying parameters, not relying on individual, personal approaches - So steps are: (1) Get things working in dd4hep (2) Ensuring that there will be multiple reco paths (not just IRT 1) (3) And identifying changes needed to the data model Chandra - To clarify step 2: user doesn't need to know guts of IRT 1 vs. IRT 2; interface is similar - Then we need to clarify data model changes: do we need to change things for the optical photon? That's for discussion ---------- Shujie - Reminder, there is another talk scheduled for today, so goal is to discuss big picture items - We can schedule another meeting for technical items ---------- Wouter - If there is a need to add things to the data model, please work out a proposal to present at the collaboration meeting Chandra - I see, so is it okay to have our own data model and we continue development with that? Wouter - No: you can have a fork that is converging TOWARDS being integrated that you can test and do development with - But it MUST converge with the data model: this to ensure that people can read your data years later Chandra - I see. Thanks! Markus - Let's make sure we discuss via email to arrive at a concrete plan for integration to discuss at the CM - If we can't, then it might be time to look at another possible baseline for testing Chandra - Makes sense; we had a meeting previously between pfRICH and dRICH teams to lay out plans for common PID reconstruction between the two - Effort is being organized by Brian - But that was before Christmas, so not much progress yet - Hope is instead have a "top-down" approach and collaborative approach to addressing this Markus - Indeed: for clarification, it's not just about avoiding siloing, but also making this developmet transparent for the WHOLE collaboration - i.e. no DSC black holes - This lets other groups see what's happening and check things from their perspective Chandra - Fully agreed ---------- Shujie - We have 10 minutes, do you want to give a brief update before the CM Nathan? Nathan - Sure! External Wiring in EICrecon Nathan Brei =========================== - This is about getting the wheels moving on external wiring, which was promised a year ago - We use JOmniFactory for interfacing with algorithmns, and then JOmniFactoryGenerator for wiring specific instances of an JOmniFactory - i.e. JOmnifactoryGenerator makes unique factory for each time you need it - Big advantage over GlueX codebase since there they copy-paste factories several times to do the same thing in different cases - Issues on the OmniFactory side: - There's no reason why "external wiring" is unique to ePIC; Jana2 broadly could make use of this - And there are a lot of factory classes in Jana2 (e.g. JMultiFactory) - CRTP means all callbacks need to be implemented ---------- Wouter - Could it be that the CRTP be more efficient than the polymorphism? Nathan - Not necessarily: the plugin architecture means we have to have a virtual call somewhere - And we don't know exactly WHAT the cost of our function calls will be - So we don't want to rewrite our whole codebase ---------- - Issues on the OmniFactoryGenerator side: - Existing wiring looks like data but you have to recompile to make changes - Existing wiring can't be added/removed - JOmniFactory's can't be used with JFactoryGenerator - So introducing JWriredFactoryGenerator - PR only introduces this, no changes to existing wiring - This is just to keep it small and not bite off more than we can chew - You feed generator a TOML file which is formatted like the existing plugins - So, like the plugin, you specify a map of factories to generate with their parameters - Completed: - PR is ready and waiting; test cases passed - TODO: - Some less-than-desirable things - You have a new parameter to specify the wiring file, and it does NOT look for a default - Also everything is formatted as strings, which could be improved - We need to decide how to handle multiple wiring files - Also should get JOmniFactory:Podio{Input,Output} ctors should accept default tags ---------- Wouter - In some cases, we've had people doing clever things by (e.g.) adding code to the plugins and programmatically filling things in - Is there a way to replicate this? Maybe have a key store that can be reused? Nathan - Yes, we could do that Wouter - And what about generating classes in TOML? Nathan - So the "prefix" value is what defines an instance of a class Dima - How will default tags for JOmnifacotry::Podio* help you? Nathan - In PODIO universe, tags need to be unique; in non-PODIO universe tags need to be unique only up to the collection name - Working towards resolving this confusion ---------- - Tactiacl improvements for EICrecon: - n.b. None of this is critical, but wanted to keep you all in the loop - Refactor: - reorganize class hierarchy: JFactory takes on JFactoryT OR JOmniFactoryT - Introduce JDataBundle to separate storage from usage - Small syntatic change for user, but HUGE change under the hood (will remove chain of inheritances going from JFactory to JOmnifactory) - JFactoryT becomes the interface for GlueX, and JOmnifactoryT becomes the interface for all the EIC extensions - Almost there: not yet working in EICrecon, and JFactoryT needs to be udpated to use JDataBundle Discussion ---------- Markus - Thank you for the effort - Question for all: we now have TOML files, this will help make development easier - But also will help make reco more accessible (just need to change parameters in TOML file) - But we need to make our code discoverable: so how do we document what parameters are? - e.g. should there be a TOML file for each directory, should there be one big TOML file...? Nathan - IMO we always want multiple views of same data; so we sould have minimal files for each directory, but we should also have the tools to generate a single, big file spelling out the entire wiring - BUT that shouldn't be the default: default should be minimal files - We don't want to end up with several MB text files with ALL parameters to set - Instead aim for all algorithms/factories come with sensible default value and users overwrite as needed Markus - So defaults are stored in c++ code? Nathan - Yes: but maybe we should get rid of the old Config text files Shujie - Question: so what does this mean for the user? Do they need to do anything different? Nathan - Nope! Markus - What about CLI arguments? Nathan - Yes, command line arguments still overwrite parameters - There are 3 levels: plugin (c++), wiring file, and command line Markus - What about documenting this? i.e. how do indicate what each parameter means? Nathan - We can set it up so that it pulls the docstrings from the c++ code to puts it as comments in the wiring file - Also, fun fact: SOLiD wants to reuse EICrecon BUT with this external wiring, so this is for them as well Markus - Who in SOLiD is asking you for these features? We should talk to them to see where we can reuse stuff and bring their efforts into ePIC Nathan - Chao Peng and Zhiwen Jiao