search

JeffersonLab / JANA2

Multi-threaded HENP Event Reconstruction
https://jeffersonlab.github.io/JANA2/
Other
6 stars 9 forks source link

Omny, Cozy, the GOAT factories on JANA2 level #276

Open DraTeots opened 4 months ago

DraTeots commented 4 months ago

For the record, OmniFactories are completely broken for outside of PodIO cases and if one uses Parameter and not ParameterRef. I actually took OmniFactory code and made my own theme park such factory but without input-output tag names and idea of underlying independant algorithm+config struct for each factory. There are some other improvements.

Not to intersect with OmniFactoris I called it CozyFactory

Fun fact. "Cozy" sounds close to "Kozeey" which translates as "goat", which gives us The GOAT Factory

Working with the GOAT/Omni factories instead of usual JFactories:

Pros:

  1. Much more fun and easier to handle
  2. Like those declarations and use of things like values = m_whatever_input()
  3. Even more like outputs streamlined m_my_output().push_back(result)
  4. In real data apps where events might be different in terms what data is in, it is good to have fail-proof stub for when there is no input data.
  5. I feel like such declarative declarations of factory needs are more clean in terms of general architecture

Cons:

  1. Having hidden Process that catches exceptions and makes it harder to debug but that deserves a separate bug report for JException.
  2. I feel like such declarative declarations of factory needs are not fully inline with the overal current JANA2 design

Thoughts:

  1. After working with them you want such API to be consistent, firstable for Processors and EventSources level
  2. With the current paradigm, IDK how much Parameters are extensible for users
  3. I understand that both OmniFactories and CozyFactories are crafted for needs and designes of particular reconstruction software and creating such things on JANA2 level so that they are universal might be impossible. But the overal design pattern is good and plesant to use.
  4. With 3 one at least can put it to examples.
  5. How python would work with it?
nathanwbrei commented 4 months ago

What's wrong with Parameter? Can you provide a test case?

nathanwbrei commented 4 months ago

I'm working on upstreaming the omnifactory machinery (Parameter, Input, Output, Service, Resource) into JANA itself, uniformly across all components (EventSource, EventProcessor, EventUnfolder, JFactory, JMultiFactory)

DraTeots commented 3 months ago

It is rather difficulties with parameter management I foresee than bugs. And basically goes about how users would write their own Parameter classes. If they want to extend the functinality.

DraTeots commented 3 months ago

Ah, and maybe it is a good idea to add ExistingParameter that will utilize a parameter that is known to be used somewhere else. How same parameters should properly be handled between classes of the same plugin or between plugins? E.g. in FL4FPGA we have a a parameter number of SRS timebins, which should be provided for EVIO reader, DQM processor and GEM reconstruction. And it should be the same value to function properly.

nathanwbrei commented 3 weeks ago

Breaking this conversation down into actionable items so that I can close the issue someday: