Project

General

Profile

Actions

Bug #2391

closed

Crash in STS digitizer during event-by-event digitization

Added by Oleg Golosov 4 months ago. Updated 4 months ago.

Status:
Closed
Priority:
Urgent
Assignee:
Oleg Golosov
Target version:
Start date:
01/18/2022
Due date:
% Done:

100%

Estimated time:

Description

About 3% of jobs (100 events each) crash during event-by-event digitization with the following error:

CbmStsDigi::SetTime(double): Assertion `dNewTime <= kMaxTimestamp' failed

The error does not occur in time-based digitization using the same transport files.

Example files and logs can be found in the following location:
/lustre/cbm/users/ogolosov/mc/cbmsim/dec21_fr_18.2.1_fs_jun19p2/dcmqgsm_smm/auau/12agev/mbias/sis100_electron_APR21/ebe/22

CbmRoot: dec21_patches f4034640
FairRoot: 18.2.1
FairSoft: jun19p2


Related issues

Related to Simulation - Sim-Development #2358: Zero-length StsPoints from transport simulationIn ProgressVolker Friese12/01/2021

Actions
Actions #1

Updated by Volker Friese 4 months ago

Actions #2

Updated by Volker Friese 4 months ago

  • Status changed from New to In Progress
  • Assignee changed from Pierre-Alain Loizeau to Volker Friese
  • Priority changed from Normal to Urgent

This is most probably connected to #2358. It seems to be connected to a G4 bug in the jun19 version. What puzzles me here is that it happens in event-by-event simulation, where I did not expect CbmStsDigi::SetTime() to be called at all. I will investigate.

Actions #3

Updated by Volker Friese 4 months ago

  • Status changed from In Progress to Feedback
  • Assignee changed from Volker Friese to Oleg Golosov

I had a look into the things and seem to understand. The unphysical times reported in #2358, related to the G4 version of fairsoft jun19, do not cause a formal problem in time-based simulation, since then the digi time is expressed relative to the time slice start, so it can never be larger than the time slice duration. In event-based simulation, all data go into a single time slice, which is then excessively large in time, and the digi time will exceeds its numerical limits, which is caught in the assert.

Oleg, could you confirm that you did the time-based simulation with real time-slice length, and not with time-slice length -1, meaning all data into one time slice?

Actions #4

Updated by Oleg Golosov 4 months ago

The time-slice length was set to -1.

Sorry I realized that I'd moved the simulation files. If needed, they can be found here:
/lustre/cbm/users/ogolosov/mc/cbmsim/dec21_fr_18.2.1_fs_jun19p2/dcmqgsm_smm/auau/12agev/mbias/sis100_electron_APR21/ebe/raw/7_

Actions #5

Updated by Oleg Golosov 4 months ago

  • Assignee changed from Oleg Golosov to Volker Friese
Actions #6

Updated by Volker Friese 4 months ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Volker Friese to Oleg Golosov
  • % Done changed from 0 to 90

If you simulate with time slice length -1, I cannot understand why the problem did not show up.

However, let's not worry too much about problems which do not show up, but concentrate on those which do. In event-by-event, this should be fixed with MR 669.

Actions #7

Updated by Oleg Golosov 4 months ago

  • Status changed from Resolved to Closed
  • % Done changed from 90 to 100

Bug fixed

Actions

Also available in: Atom PDF