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