Digitizer: Make digi time relative to the start of the time slice.

This MR changes the digi time from a global timestamp to one that is relative to the start of the time slice. A time offset is now also applied in event-by-event mode to prevent negative timestamps in digis. These changes are in preparation for the updated 8 byte STS digi (MR !355 (merged)).

Also see discussion in issue #2131.

changed title from Digitizer: Make digi time relative to the start of the time frame. to Digitizer: Make digi time relative to the start of the time slice.

changed the description

Dear @f.uhlig, @v.friese, @p.-a.loizeau, @c.muentz, @m.deveaux, @v.singhal, @karpushkin_AT_inr.ru, @s.lebedev, @n.herrmann, @i.deppner, @praisig,

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

Fine for the TRD part.

assigned to @v.friese

added 10 commits

• bc62c4a0...a27006d2 - 8 commits from branch computing:master
• 8954d2fe - Digitization: Apply time offset also in event-by-event mode.
• 5ef190d6 - Digitization: Make digi timestamp relative to the beginning of the time slice.

Compare with previous version

Updated the MR to keep the global time for event-by-event mode and flexible time slices.

added 3 commits

• 19e02e79 - 1 commit from branch computing:master
• 0104623f - Digitization: Apply time offset also in event-by-event mode.
• 5fb1a779 - Digitization: Make digi timestamp relative to the beginning of the time slice.

Compare with previous version

added 3 commits

• 6b575da0 - 1 commit from branch computing:master
• a5e01683 - Digitization: Apply time offset also in event-by-event mode.
• 2e8fd764 - Digitization: Make digi timestamp relative to the beginning of the time slice.

Compare with previous version

added 31 commits

• 2e8fd764...dc689994 - 29 commits from branch computing:master
• 536aef61 - Digitization: Apply time offset also in event-by-event mode.
• 41a86955 - Digitization: Make digi timestamp relative to the beginning of the time slice.

Compare with previous version

added 25 commits

• 41a86955...ef98dfa2 - 23 commits from branch computing:master
• 53c05c05 - Digitization: Apply time offset also in event-by-event mode.
• 137995f0 - Digitization: Make digi timestamp relative to the beginning of the time slice.

Compare with previous version

added 3 commits

• 4f121731 - 1 commit from branch computing:master
• 9bc038a9 - Digitization: Apply time offset also in event-by-event mode.
• 84a102e0 - Digitization: Make digi timestamp relative to the beginning of the time slice.

Compare with previous version

added 55 commits

• 84a102e0...0157edc9 - 53 commits from branch computing:master
• 811ca7ae - Digitization: Apply time offset also in event-by-event mode.
• 0c3ce0e0 - Digitization: Make digi timestamp relative to the beginning of the time slice.

Compare with previous version

added 18 commits

• 0c3ce0e0...c649d98b - 16 commits from branch computing:master
• 9baaec78 - Digitization: Apply time offset also in event-by-event mode.
• 403cabf3 - Digitization: Make digi timestamp relative to the beginning of the time slice.

Compare with previous version

added 8 commits

• 403cabf3...e3c61ebc - 6 commits from branch computing:master
• 9ad00b60 - Digitization: Apply time offset also in event-by-event mode.
• 13ba0915 - Digitization: Make digi timestamp relative to the beginning of the time slice.

Compare with previous version

added 3 commits

• 063891f0 - 1 commit from branch computing:master
• 6e2d1ba4 - Digitization: Apply time offset also in event-by-event mode.
• 1234e8f1 - Digitization: Make digi timestamp relative to the beginning of the time slice.

Compare with previous version

mentioned in merge request !355 (merged)

@o.golosov, @v.klochkov,

could you please have a look why the test at_kfpf_sis100_electron fails for this MR. The test only fails for the FairSoft versions nov20 and apr21 so it may be connected to ROOT. For me it looks like that the test hangs in some initialisation and is terminated after 300 seconds. The only output one gets is

   ------------------------------------------------------------------
  | Welcome to ROOT 6.22/08                        https://root.cern |
  | (c) 1995-2020, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on Mar 10 2021, 14:20:04                 |
  | From tags/v6-22-08@v6-22-08                                      |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q'       |
   ------------------------------------------------------------------


Processing /u/uhlig/cbm/cbmroot_git/macro/analysis/common/at_kfpf_interface/run_at_kfpf.C(20,"data/sis100_electron_test")...
ATKFParticleFinder::InitInput()

and I ave no idea how to further debug the problem.

@o.golosov, @fweig

if I run the macro locally without the test suite I get slightly more output

Processing /u/uhlig/cbm/cbmroot_git/macro/analysis/common/at_kfpf_interface/run_at_kfpf.C(20,"data/sis100_electron_test")...
ATKFParticleFinder::InitInput()
ATKFParticleFinder::InitOutput()
ATKFParticleFinder::Run() 20 events
eveNo = 0
663

@o.lubynets,

could you try to run as a test the complete chain of macros from the macro/C2F directory.

To do so simply run make test in the directory macro/C2F in your build directory. This will create new input files and then runs the analysis.

added 4 commits

• 1234e8f1...a218edbf - 2 commits from branch computing:master
• 3acc786d - Digitization: Apply time offset also in event-by-event mode.
• 3a172bf2 - Digitization: Make digi timestamp relative to the beginning of the time slice.

Compare with previous version

I tested the MR, comparing to the current upstream HEAD, with "standard" simulation and reconstruction. I compare just the numbers of produced objects in 10 events (same transport input in order to avoid fluctuation due to random number).

I find agreement in the number of digis (from simulation) and hits (from reconstruction) for all detector systems, but the number of StsTracks increases dramatically (from 4478 in HEAD to 6747 with the MR).

So, there seems to be an issue with CA tracking. We have to ask Valentina to have a look.

@v.friese, forget my previous comment, I had the wrong setup..

Btw, I can not write comments on the redmine issue, probably I don't have permissions.

added 12 commits

• 3a172bf2...bfcc4b60 - 10 commits from branch computing:master
• 8739e776 - Digitization: Apply time offset also in event-by-event mode.
• 43d71ef8 - Digitization: Make digi timestamp relative to the beginning of the time slice.

Compare with previous version

@v.friese @se.gorbunov Just rebased the MR to include Valentinas fix (!477 (merged)).

After the MR now passes the pipeline we should check if we can use the schema evolution to allow backward compatibility of the digi data.

added 39 commits

• 43d71ef8...365a9936 - 36 commits from branch computing:master
• 5d6f80e2 - Digitization: Apply time offset also in event-by-event mode.
• 2237f5bb - Digitization: Make digi timestamp relative to the beginning of the time slice.
• f764f565 - Fix SetTime method for SPADIC-type CbmTrdDigi

Compare with previous version

added 1 commit

• 79ce8061 - Fix license headers

Compare with previous version

resolved all threads

merged

We have to keep in mind that this MR breaks backward compatibility.

Yes, but this was announced already on 2 July in https://redmine.cbm.gsi.de/news/402, without complaints.