online: Add chain enum to select full reconstruction steps.

Changes:

• Replaces the --steps option in cbmreco with --chain,-x
• --chain takes a single argument to select reconstructions steps and a trigger type
• Possible values are:
  • Unpack,
  • DigiTrigger (Unpack + DigiTriggering),
  • Hitfind (Unpack + Hitfinding),
  • HitTrigger (Hitfind + Hit triggering),
  • CA (Unpack + Hitfinding + Tracking),
  • V0 (Tracking + V0 trigger)
• In parameters/online added one config file per trigger type.

TODO:

• Merge parameter update: CbmSoft/cbmroot_parameter!185

added Online Parameters labels

requested review from @v.friese

assigned to @fweig

added 1 commit

• 70ac979e - Fix realdata test.

Compare with previous version

I was thinking in a similar direction here: to define the relation between processing steps, trigger and required output. This MR reflects the current situation. However, my approach was slightly different.

In production mode, the online process will select DigiEvents from fles timeslices. Any other mode is for debugging / offline from tsa. Thus, an online run should be defined by the selected trigger type. I would thus make the trigger definition a command line option, and hard-code the relation to the steps and outputs:

• Trigger DigiMult: Steps Unpack Eventbuilding; Output DigiEvent
• Trigger HitMult: Steps Unpack Hitfinding Eventbuilding; Output DigiEvent
• Trigger V0: Steps Unpack Hitfinding Tracking Eventbuilding; Output DigiEvent

In addition, we have to define the debugging modes (without trigger):

• just run unpacking; save DigiTimeslice
• run (partial) reconstruction and save the results to file

We can merge this MR and come back to the issues after the current beamtime, or leave it as is for the beamtime and make a proper implementation afterwards. I would tend to the second option, being reluctant to introduce an intermediate solution during data taking.

Like to hear the opinion of @j.decuveland .

I am very much in favor of this change in general. I also think we should hardcode a number of useful processing chains and select them using a single operation mode parameter.

In my opinion, the cbmreco binary should be opinionated and expose mostly functionality that makes sense to actually use. It should not try to reimplement the maximum flexibility that we have in macro files.

I do not yet understand the fundamental difference between your two suggestions. In my mind, we mostly group the parameters by whether they are mutually exclusive, which would make them a mode-type parameter, or whether they are optional, making them an independent switch. The distinction between production and debugging modes does not seem to be the most important to me at this level.