Project

General

Profile

Actions

Bug #1685

closed

Assertion fail for TRD time based digitization

Added by Vikas Singhal over 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
High
Assignee:
Target version:
Start date:
04/17/2020
Due date:
% Done:

100%

Estimated time:

Description

Hello,

during running run_digi.C macro for sis100_muon_lmvm setup for more than 100 events including STS, MUCH, TRD, TOF detector getting error as below:- ========================
root.exe: /lustre/nyx/cbm/users/vsinghal/timebasedtrunk/core/base/CbmDigitize.h:302: ULong64_t CbmDigitize<Digi>::FillTimeSlice(CbmTimeSlice*, Bool_t, Double_t) [with Digi = CbmTrdDigi; ULong64_t = long long unsigned int; Bool_t = bool; Double_t = double]: Assertion `(! checkMinTime) || it->first >= tMin' failed. =========================

If run similar without TRD digitization.

run.Deactivate(kTrd);

then do not get any error.

Kindly Check,
Vikas

Actions #1

Updated by Volker Friese over 2 years ago

  • Status changed from New to In Progress
  • Assignee changed from Volker Friese to Vikas Singhal

Which software version do you use? I have done a correction concerning this about a week ago.

Actions #2

Updated by Vikas Singhal over 2 years ago

Dear Volker,

Earlier I used Revision: 16125.

and I updated the revision 16180 but still getting the same error.

==================================
[INFO] DigitizationSource: Event 191 at t = 22142.506 ns from input 0 (entry 191)
[INFO] + StsDigitize: Generated 2262 noise signals from t = 22086.2 ns to 22142.5 ns
[INFO] StsDigitize [0.867 s] Points: processed 4275, ignored 0, signals: 20867 / 20567, digis: 18171
[INFO] + MuchDigitizeGem: Event 191 at 22142.506 ns, points: 3236, signals: 4993, digis: 3572. Exec time 0.054657 s.
[INFO] + TrdDigitize: Event 191 at 22142.506 ns, points: 61, digis: 154. Exec time 0.022970 s.
[INFO] + TofDigitize: Event 191 at 22142.506 ns, points: 556, digis: 242. Exec time 0.001744 s.
root.exe: /lustre/nyx/cbm/users/vsinghal/timebasedtrunk/core/base/CbmDigitize.h:308: ULong64_t CbmDigitize<Digi>::FillTimeSlice(CbmTimeSlice*, Bool_t, Double_t) [with Digi = CbmTrdDigi; ULong64_t = long long unsigned int; Bool_t = bool; Double_t = double]: Assertion `(! checkMinTime) || it->first >= tMin' failed.

==============================
Regards
Vikas

Actions #3

Updated by Etienne Bechtel over 2 years ago

Hello Vikas,

could you please make an update of your TRD software and report back, if you are still seeing this issue?
I have an idea of what could have been happening and it should be resolved by now.
Your revision was after the change of the GetTime() function in the TrdDigi class from revision 16154 and before changes in the simulation in 16274.

Best regards
Etienne

Actions #4

Updated by Volker Friese over 2 years ago

Dear Vikas,

is the issue resolved by Etienne's update?

Actions #5

Updated by Vikas Singhal over 2 years ago

Dear Etienne and Volker,

It looks problem not resolved after update and also disabled noise. Details below:- =================
Revision: 16462
Input File: same as earlier muon_1k.tra.root (Generated using 1000 UrQMD and embedded Pluto events)
Event Rate: 10^7
TimeSlice : 10^4

CbmDigitization run;
run.AddInput(inFile, eventRate);
run.SetOutputFile(outFile, overwrite);
run.SetMonitorFile(monFile);
run.SetParameterRootFile(parFile);
run.SetTimeSliceLength(timeSliceLength);
run.SetEventMode(eventMode);
run.SetProduceNoise(kFALSE); // disable Noise generation
run.Run(nEvents);

Output:- TRD related Output only
Container FairGeoParSet initialized from ROOT file.
[INFO] CbmDigitization: Adding parameter file /lustre/nyx/cbm/users/vsinghal/mcbm2020/parameters/trd/trd_v17n_1m.asic.par
[INFO] CbmDigitization: Adding parameter file /lustre/nyx/cbm/users/vsinghal/mcbm2020/parameters/trd/trd_v17n_1m.digi.par
[INFO] CbmDigitization: Adding parameter file /lustre/nyx/cbm/users/vsinghal/mcbm2020/parameters/trd/trd_v17n_1m.gain.par
[INFO] CbmDigitization: Adding parameter file /lustre/nyx/cbm/users/vsinghal/mcbm2020/parameters/trd/trd_v17n_1m.gas.par
[INFO] CbmDigitization: Adding parameter file /lustre/nyx/cbm/users/vsinghal/mcbm2020/parameters/tof/tof_v16c_1m.digi.par
[INFO] CbmDigitization: Adding parameter file /lustre/nyx/cbm/users/vsinghal/mcbm2020/parameters/tof/tof_v16c_1m.digibdf.par
:
:
[INFO] CbmTrdContFact::createContainer :CbmTrdParSetAsic
[INFO] CbmTrdContFact::createContainer :CbmTrdParSetGas
[INFO] CbmTrdContFact::createContainer :CbmTrdParSetDigi
[INFO] CbmTrdContFact::createContainer :CbmTrdParSetGain
:
:
[INFO] Object TrdPoint describing the branch in the folder structure was found
[INFO] ================CbmTrdRadiator===============
[INFO] CbmTrdRadiator::Init : Prototype : K++
[INFO] CbmTrdRadiator::Init : Scaling factor : 0.65
[INFO] CbmTrdRadiator::Init : Foil material : pokalon
[INFO] CbmTrdRadiator::Init : Nr. of foils : 350
[INFO] CbmTrdRadiator::Init : Foil thickness : 0.0024 cm
[INFO] CbmTrdRadiator::Init : Gap thickness : 0.07 cm
[INFO] CbmTrdRadiator::Init : Simple TR production: 1
[INFO] CbmTrdRadiator::Init : Foil plasm. frequ. : 22.5 keV
[INFO] CbmTrdRadiator::Init : Gap plasm. frequ. : 0.7 keV
[INFO] CbmTrdRadiator::Init : Window density : 1.42 g/cm^3
[INFO] CbmTrdRadiator::Init : Window thickness : 0.0025 cm
[INFO] CbmTrdGas::Init: Detector type : standard GSI geometry (2)
[INFO] CbmTrdGas::Init: Gas thickness : 1.2 cm
[INFO] CbmTrdGas::Init: Percent (Xe) : 85
[INFO] CbmTrdGas::Init: Percent (CO2) : 15
[INFO] CbmTrdRadiator::Init : Detector noble gas : 0.85
[INFO] CbmTrdRadiator::Init : Detector cruncher gas: 0.15
[INFO] CbmTrdRadiator::Init : Detector type : 0
[INFO] CbmTrdRadiator::Init : Detector gas thick. : 1.2 cm
[INFO] TrdDigitize: Registered branch TrdDigi
[INFO] TrdDigitize: Registered branch TrdDigiMatch
[INFO] ================ TRD Digitizer ===============
[INFO] Free streaming : yes
[INFO] Add Noise : no
[INFO] Weighted distance : no
:
:
[INFO] ===================================================
[INFO] CbmDigitization: Starting run...
[INFO] MCInputSet: Max. number of events for input 0 is 1000
[INFO] MCInputSet: Maximal number of events is 1000
[INFO] FairRunAna::Run() After checking, the run will run from event 0 to 1000.

[INFO] DigitizationSource: Event 0 at t = 1809.967 ns from input 0 (entry 0)
[INFO] StsDigitize [0.479 s] Points: processed 3694, ignored 0, signals: 17382 / 16980, digis: 0
[INFO] + MuchDigitizeGem: Event 0 at 1809.967 ns, points: 3168, signals: 4876, digis: 0. Exec time 0.049296 s.
[INFO] + TrdDigitize: Event 0 at 1809.967 ns, points: 63, digis: 0. Exec time 0.251480 s.
[INFO] + TofDigitize: Event 0 at 1809.967 ns, points: 374, digis: 167. Exec time 0.001652 s.
[INFO] Daq [0.000 s] Transported digis: 0, Buffer status: 167 data from t = 1809.94 to 2964.63 ns
:
:
[INFO] DigitizationSource: Event 198 at t = 22349.718 ns from input 0 (entry 198)
[INFO] StsDigitize [0.687 s] Points: processed 3700, ignored 0, signals: 17414 / 17144, digis: 9
[INFO] + MuchDigitizeGem: Event 198 at 22349.718 ns, points: 3756, signals: 5974, digis: 6453. Exec time 0.065425 s.
[INFO] + TrdDigitize: Event 198 at 22349.718 ns, points: 59, digis: 84. Exec time 0.020351 s.
[INFO] + TofDigitize: Event 198 at 22349.718 ns, points: 405, digis: 171. Exec time 0.001686 s.
root.exe: /lustre/nyx/cbm/users/vsinghal/mcbm2020/core/base/CbmDigitize.h:308: ULong64_t CbmDigitize<Digi>::FillTimeSlice(CbmTimeSlice*, Bool_t, Double_t) [with Digi = CbmTrdDigi; ULong64_t = long long unsigned int; Bool_t = bool; Double_t = double]: Assertion `(! checkMinTime) || it->first >= tMin' failed.

===================================

Same I run with DEBUG mode on. Output is big so some last relevant lines here. ( Full file you can access at /lustre/nyx/cbm/users/vsinghal/timebasedtrunk/TimeBasedReco/digi_all_noNoise_1000_Debug_Output )

==================================
[DEBUG] CbmTrdDigitizer::Exec Points: 59
[DEBUG] CbmTrdDigitizer::Exec PointsAboveThreshold: 59
[DEBUG] CbmTrdDigitizer::Exec Digis: 84
[DEBUG] CbmTrdDigitizer::Exec digis/points: 1.42373
[DEBUG] CbmTrdDigitizer::Exec BackwardTracks: 8
[DEBUG] CbmTrdDigitizer::Exec LatticeHits: 3
[DEBUG] CbmTrdDigitizer::Exec Electrons: 26
[DEBUG] CbmTrdDigitizer::Exec latticeHits/electrons:0.115385
[DEBUG] CbmTrdDigitizer::Exec real time=0.0206978 CPU time=0.02
[INFO] + TrdDigitize: Event 198 at 22349.718 ns, points: 59, digis: 84. Exec time 0.020698 s.
:
:
[DEBUG] Daq Buffer status: 2367817 data from t = 29 to 29629.6 ns
[DEBUG] Daq: Fill time is 20325.6 ns
[DEBUG] Daq: Fill time slice up to t = 20325.6 ns
[DEBUG] Daq Buffer status: 2367817 data from t = 29 to 29629.6 ns
STS Status DAQ buffer: 1941895 data from t = 10000 to 21533 ns
MUCH Status DAQ buffer: 385408 data from t = 10002 to 21949 ns
TRD Status DAQ buffer: 19147 data from t = 29 to 342 ns
TOF Status DAQ buffer: 21367 data from t = 10003.3 to 29629.6 ns
[DEBUG] Daq: Time slice [10000, 20000] ns, data: empty
root.exe: /lustre/nyx/cbm/users/vsinghal/mcbm2020/core/base/CbmDigitize.h:308: ULong64_t CbmDigitize<Digi>::FillTimeSlice(CbmTimeSlice*, Bool_t, Double_t) [with Digi = CbmTrdDigi; ULong64_t = long long unsigned int; Bool_t = bool; Double_t = double]: Assertion `(! checkMinTime) || it->first >= tMin' failed.
vsinghal@lxbk0195:/lustre/nyx/cbm/users/vsinghal/timebasedtrunk/TimeBasedReco$ ==========================

Regards
Vikas

Actions #6

Updated by Volker Friese over 2 years ago

I cannot confirm the findings.

I have transported 500 central UrQMD events in a TRD-only setup. Everything goes fine. I have employed the same settings as you (event rate 10^7, time-slice length 10^4).

I use the current trunk (r14642).

What I noticed in the process, though, is that switching the noise on and off through CbmDigitization has no effect for the TRD. It probably has and uses an internal flag, not the one inherited from CbmDigitizeBase.

Actions #7

Updated by Vikas Singhal over 2 years ago

Dear Volker,

Probably you did not get any error as you enabled only TRD. I tried to look into the debug output and it looks that TRD generate very old digi time also. Means DAQ already closed the time slice 0-10000 ns but when DAQ try to save next time slice 10000-20000 in this it encounter TRD digis from 29ns.

Below shows DAQ could successfully close first time slice as there was no TRD digi till 10000ns (do not know why.) =========
[DEBUG] Daq Buffer status: 2089986 data from t = 29 to 17512.3 ns
[DEBUG] Daq: Fill time is 10044.3 ns
[DEBUG] Daq: Fill time slice up to t = 10044.3 ns
[DEBUG] Daq Buffer status: 2089986 data from t = 29 to 17512.3 ns
STS Status DAQ buffer: 1708341 data from t = 1792 to 11347 ns
MUCH Status DAQ buffer: 351653 data from t = 1818 to 11768 ns
TRD Status DAQ buffer: 10332 data from t = 29 to 184 ns
TOF Status DAQ buffer: 19660 data from t = 1809.94 to 17512.3 ns
[DEBUG] Daq: Time slice [0, 10000] ns, data: empty
[DEBUG] Daq: Fill data: STS 1483868 MUCH 280138 TRD 10332 TOF 14658
[DEBUG] Daq Buffer status: 300990 data from t = 10003.3 to 17512.3 ns
STS Status DAQ buffer: 224473 data from t = 10000 to 11347 ns
MUCH Status DAQ buffer: 71515 data from t = 10002 to 11768 ns
TRD Status DAQ buffer: 0 data from t = -1 to -1 ns
TOF Status DAQ buffer: 5002 data from t = 10003.3 to 17512.3 ns
[DEBUG] DaqTime slice [0, 10000] ns, data: [29.000, 9999.000] ns, STS 1483868 MUCH 280138 TRD 10332 TOF 14658 , MC events 98
[DEBUG] Daq: total 14658 moved
[INFO] Daq: Closing Time slice [0, 10000] ns, data: [29.000, 9999.000] ns, STS 1483868 MUCH 280138 TRD 10332 TOF 14658 , MC events 98
[INFO] Daq: Current MC event range: empty
[INFO] Daq Buffer status: 300990 data from t = 10003.3 to 17512.3 ns
[INFO] Daq [5.368 s] Transported digis: 1788996, Buffer status: 300990 data from t = 10003.3 to 17512.3 ns ===========================

Now DAQ try to close next time slice from 10000-20000 ns, but crash as TRD digi time start from 29ns.

===========================
[DEBUG] Daq Buffer status: 2367817 data from t = 29 to 29629.6 ns
[DEBUG] Daq: Fill time is 20325.6 ns
[DEBUG] Daq: Fill time slice up to t = 20325.6 ns
[DEBUG] Daq Buffer status: 2367817 data from t = 29 to 29629.6 ns
STS Status DAQ buffer: 1941895 data from t = 10000 to 21533 ns
MUCH Status DAQ buffer: 385408 data from t = 10002 to 21949 ns * TRD Status DAQ buffer: 19147 data from t = 29 to 342 ns*
TOF Status DAQ buffer: 21367 data from t = 10003.3 to 29629.6 ns
[DEBUG] Daq: Time slice [10000, 20000] ns, data: empty
root.exe: /lustre/nyx/cbm/users/vsinghal/mcbm2020/core/base/CbmDigitize.h:308: ULong64_t CbmDigitize<Digi>::FillTimeSlice(CbmTimeSlice*, Bool_t, Double_t) [with Digi = CbmTrdDigi; ULong64_t = long long unsigned int; Bool_t = bool; Double_t = double]: Assertion `(! checkMinTime) || it->first >= tMin' failed. ======================================

I changed Time Slice length to 1000 and 10^6 rate, then encountered same after 10 Time slices

=======================================
[DEBUG] Daq: Time slice [9000, 10000] ns, data: empty
[DEBUG] Daq: Fill data: STS 16959 MUCH 3536 TRD 0 TOF 163
[DEBUG] Daq Buffer status: 116625 data from t = 10253.7 to 14093.9 ns
STS Status DAQ buffer: 93689 data from t = 10377 to 12716 ns
MUCH Status DAQ buffer: 21809 data from t = 10192 to 13126 ns
TRD Status DAQ buffer: 0 data from t = 1 to -1 ns
TOF Status DAQ buffer: 1127 data from t = 10253.7 to 14093.9 ns
[DEBUG] DaqTime slice [9000, 10000] ns, data: [9081.000, 9798.976] ns, STS 16959 MUCH 3536 TOF 163 , MC events 1
[DEBUG] Daq: total 163 moved
[INFO] Daq: Closing Time slice [9000, 10000] ns, data: [9081.000, 9798.976] ns, STS 16959 MUCH 3536 TOF 163 , MC events 1
[INFO] Daq: Current MC event range: empty
[INFO] Daq Buffer status: 116625 data from t = 10253.7 to 14093.9 ns
[INFO] Daq [0.039 s] Transported digis: 20658, Buffer status: 116625 data from t = 10253.7 to 14093.9 ns
:
:
[DEBUG] Daq Buffer status: 137032 data from t = 145 to 18050.5 ns
[DEBUG] Daq: Fill time is 11530.8 ns
[DEBUG] Daq: Fill time slice up to t = 11530.8 ns
[DEBUG] Daq Buffer status: 137032 data from t = 145 to 18050.5 ns
STS Status DAQ buffer: 113373 data from t = 10377 to 13078 ns
MUCH Status DAQ buffer: 22363 data from t = 10192 to 13548 ns
TRD Status DAQ buffer: 28 data from t = 145 to 185 ns
TOF Status DAQ buffer: 1268 data from t = 10253.7 to 18050.5 ns
[DEBUG] Daq: Time slice [10000, 11000] ns, data: empty
root.exe: /lustre/nyx/cbm/users/vsinghal/mcbm2020/core/base/CbmDigitize.h:308: ULong64_t CbmDigitize<Digi>::FillTimeSlice(CbmTimeSlice*, Bool_t, Double_t) [with Digi = CbmTrdDigi; ULong64_t = long long unsigned int; Bool_t = bool; Double_t = double]: Assertion `(! checkMinTime) || it
>first >= tMin' failed.

=================================

Regards
Vikas

Actions #8

Updated by Etienne Bechtel over 2 years ago

Hello Vikas,

I have a theory of what could be happening now.
The reason could be due to the comparably low amount of MC points in the TRD in the muon setup, which could lead to routines, which are supposed to process the buffer, that are not called in time before the timeslice is finished. I will have a second look into it and let you know.

Best regards
Etienne

Edit: However, i am still confused that they are supposed to be located at such an early time... I will look into it

Actions #9

Updated by Volker Friese over 2 years ago

  • Target version changed from APR20 to APR21

I simulated the full setup (sis100_muon_lmvm), but did not see such occurences in 500 events.

As discussed in the software meeting of 28 May 2020, I shift this issue from the target APR20.

Actions #10

Updated by Vikas Singhal over 2 years ago

Dear Volker and Etienne,

Strange, I could not find this Assertion fail problem with APR20 release, but problem is persisting in the development trunk branch though I updated with r16507 also.

To crosscheck I have installed another cbmroot development branch in the GSI cluster and also in my own desktop. But same problem.

I do not know the reason but TRD time based digi creation is working with APR20 release but not with development branch.

Regards
Vikas

Actions #11

Updated by Florian Uhlig over 2 years ago

Hi Vikas,

the commits to trunk were not yet ported to the development branch, so the problem may persist in the development branch but is already solved in trunk and the release. I am currently working on this issue and the fixes will also go to the development branch.

Ciao

Florian

Actions #12

Updated by Florian Uhlig over 1 year ago

Is the problem fixed? If so please close the ticket.

Actions #13

Updated by Vikas Singhal over 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Ticket may be closed.
Vikas

Actions #14

Updated by Volker Friese over 1 year ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF