online: Add one config file per Trigger type.

Dear @f.uhlig, @p.-a.loizeau, @d.emschermann,

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

mentioned in merge request computing/cbmroot!1822

if we modify the Trigger config, could you please also apply these changes to the event window that we had in the local folder?

diff --git a/online/EventbuildConfig.yaml b/online/EventbuildConfig.yaml
index 2d2c2bc..3fdc148 100644
--- a/online/EventbuildConfig.yaml
+++ b/online/EventbuildConfig.yaml
@@ -5,12 +5,12 @@ trigger:
   threshold: 8
   deadtime: 50
 eventbuilder:
-  BMON:    [-65, 65]
-  STS:   [-75, 75]
+  BMON:  [-25, 25]
+  STS:   [-80, 80]
   MUCH:  [-50, 500]
-  TRD :  [-100, 300]
+  TRD :  [-150, 150]
   TRd2D: [-100, 350]
-  TOF:   [-10, 70]
+  TOF:   [-30, 70]
   RICH:  [-20, 120]
   FSD:   [-50, 150]
 selector:

@v.friese not 100% sure however if these should be applied only in the DigiTrigger case or in all cases, as most probably the seed time will change (maybe a lot) depending on the trigger, right?

That is correct. Depending on how the trigger is derived, its time w.r.t. the other detectors (not used in the trigger) might vary. But not by a lot, I think. For both the digi multiplicity trigger and the hit multiplicity trigger, we use TOF, so there should not be strong changes in the timing. This may be different for the V0 trigger, the time of which is defined by the track pair (mean of the track times at the first attributed hit).

The trigger times should be reflected in the windows used for event building. I did not put much emphasis here since they were quite generous up to now.

A better method would be to define a good event time reference independent from the trigger (event t0). Could be the T0 measurement, but this will not be always there. Then, for each concrete trigger, an offset would be determined (by simulation or other means). So, all triggers would refer to the common reference, and the event building windows could be defined independent from the trigger. But this we do not have yet.

Plus: I am not sure (rather the opposite) that it makes sense to manage this configuration through the parameter repository. I think that discussing out strategy for the parameter / configuration management is high on the to-do list after the beamtime.

I agree. I would like to move these config files back into cbmroot. This would make sense once we generate the setup in the CI and include it in the container.