Sim-Development #2358

Zero-length StsPoints from transport simulation

Added by Volker Friese about 2 months ago. Updated about 2 months ago.

In Progress
Target version:
Start date:
Due date:
% Done:


Spent time:


It was recently found (see "MR that occasionally, there are CbmStsPoints with zero length, i.e., entry and exit points in the STS sensors are identical. Such cases have been seen with Geant4 in fairsoft jun19 at unusually large time (> 10^10 ns); they disappear with Geant4 of fairsoft apr21.

Such StsPoints will, with the current software, not be digitised even if the energy loss / charge deposit is above threshold (see CbmStsSimSensorDssd::ProduceCharge()).

To do:
  • Check whether such cases occur also with newer Geant4, Geant3 or at "normal" times.
  • Figure out whether they are physical.
  • If unphysical, catch them in the transport and/or digitisation code. If physical, see to their proper treatment in the STS digitisation.

Related issues

Related to CbmRoot - Bug #2391: Crash in STS digitizer during event-by-event digitization Resolved 01/18/2022


#1 Updated by Volker Friese about 2 months ago

  • Status changed from Assigned to In Progress
  • % Done changed from 0 to 50
I have studied the following cases:
  • run_tra_file.C with Geant3 ("_g3")
  • run_tra_file.C with Geant4 ("_g4")
  • c2f_transport.C with Geant4 ("_c2f")
    In contrast to run_tra_file.C, c2f_transport does not make use of the CbmTransport class, but uses the older scheme with direct instantiation of FairRunSim. All cases were studied with 100 events of the standard input file (UrQMD, central Au+Au, 10A GeV) and with fairsoft jun19 and apr21.

I find that cases with zero-length trajectories are present in all of these cases, albeit with different frequency:

g3:    282 (jun19)   293 (apr21)
g4:     37 (jun19)    44 (apr21)
c2f:  1017 (jun19)   866 (apr21)

Most of these have "normal" times of several ns.

CbmStsPoints at large times (> 1 ms) occur only for c2f in jun19 (156 instances). 155 of these also have zero-length trajectory, only one has a finite-size trajectory.

My interpretation of these findings:
  • Cases where a track disappears in the same space point where it was created seems to be legal; they occur in all configurations. Their frequency is roughly the same for jun19 and apr21. However, it is strongly different for Geant3 and Geant4.
  • Using Geant4, the frequency of zero-length trajectory is strongly different between run_tra_file.C and c2f_transport.C. The reason for this is unknown. There might be different Geant4 settings employed by the two macros.
  • Cases with very large, seemingly unphysical times seem to be a bug in Geant4 of the jun19 version and disappear in the apr21 version of Geant4. Why they show up, in jun19, only with c2f_transport.C and not with run_tra_file.C is unknown.
My consequences for the STS software are:
  • In digitization, throw an exception (assert) if CbmStsPoint::GetTime() is large (> 1 ms).
  • In digitization, properly treat cases where entry coordinates = exit coordinates. Currently, such CbmStsPoints are implicitly ignored (step size zero leads to zero energy loss in the Urban method).
Further investigation would address the questions:
  • Why does c2f_transport.C give different results from run_tra_file.C, both with Geant4? Are there other differences in the results beyond the strange cases studied here?
  • What processes in Geant3 or Geant4 result in tracks being absorbed in the same space point as thy are being produced in?

#2 Updated by Volker Friese about 2 months ago

For completeness, I have studied also c2f_transport.C with Geant3. No cases with unphysical times are seen. The number of zero-length CbmStsPoints is 362 (jun19) and 325 (apr21). Slightly, but not dramatically more than with run_tra_file.C with Geant3.

#3 Updated by Volker Friese 5 days ago

  • Related to Bug #2391: Crash in STS digitizer during event-by-event digitization added

Also available in: Atom PDF