Event reconstruction in online/offline

marked the checklist item Separate class cbm::algo::EventReconstruction, which performs reconstruction of digi-events (hits, tracks) as completed

changed the description

Dear @d.smith, @fweig,

you have been identified as code owner of at least one file which was changed with this merge request.

Please check the changes and approve them or request changes.

added CodeOwners label

Thanks for doing this - this is a step we definitely need in several places, online as well as offline.

Some general remarks:

I would prefer to name the class RecoEvent instead of EventReconstruction.
It should be a single step, not separated into EventLocalReco and EventTracking.
I should be configurable through a YAML file. By default, it should perform local reconstruction for all systems where input data (digis) are in the DigiEvent. There should be the option to deactivate systems even if input digis are present. By default, tracking should be performed provided at least one tracking detector is present (STS, MUCH or TRD). It should be possible to deactivate tracking.
The systems included are mCBM specific. I think we should have an implementation that suits full CBM from the start. But maybe we can add this later, so you can test this class with mCBM meanwhile.
Event reconstruction should include primary vertex finding, which is not included in this class here.
In general, this class is to replace most of the functionality of run_reco.C in the event-by-event mode.

requested review from @j.decuveland

marked the checklist item Steering class CbmEventRecoTask for the online-style digi-event reconstruction in offline as completed

marked the checklist item Steering class CbmEventRecoTask for the online-style digi-event reconstruction in offline as incomplete

Hi.

I have been added as a reviewer, so I will try to give some feedback. In general, the code looks fine to me. I must say though that I am not an expert on this part of the code. And I feel that I do not fully understand the objective. (Maybe a few more words for context in the MR would have helped me.)

What I think I understand is:

Using algo/online code, we can build events from the raw data streams (by multiplicity selector), OR we can run tracking on all (unfiltered) data. But we cannot run the tracking on previously selected events. Now this functionality is added.
Do I get this right?

If so, structurally, should the output data structure of this be stored independently of the RecoResults structure and not as a part of it?

Thanks for the clarification! I was on the right track, and I totally get that it's also for DigiEvents from simulation. Makes sense!

So, my first question still stands: should the output (RecoEvents) be part of the RecoResults structure or something else?

I've always thought of the RecoResults output structure as flexible and easy to extend, so it could hold whatever output we want. In my mind, this would work great for a future alternative output file format using Root because Root files already have the same kind of flexibility, and we'd only have to change one spot in the code.

I agree to what you said above.

In my view, the RecoEvent structure will not be made persistent in the main data path. We decided to store DigiEvents, and RecoEvents will always be reproducible from them. Online, they serve for the selection decision and can be discarded after this decision.

However, we clearly must have the option to store RecoEvents as well, if only for debugging and testing. In that sense, the RecoEvent collection should be (an optional) part of RecoResults, just as other data are now.

added 16 commits

2ee4d7b5...3ef736c3 - 15 commits from branch computing:master
d3e6ad0f - [online] moving event reconstruction in a separate class

Event reconstruction in online/offline

Merge request reports

Activity