Project

General

Profile

Actions

Bug #337

closed

FairBoxGenerator (maybe not only there): random number generator

Added by Sascha Reinecke almost 7 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
07/27/2015
Due date:
03/31/2021
% Done:

100%

Estimated time:
10.00 h

Description

This "bug" is related to the FairBoxGenerator class of FairRoot, therefore I am not sure whether this is the right place here. But as it might affect users of CbmRoot I'll post it here. If you make some simulations only including particles from the BoxGenerator the results are highly correlated (and might even be somehow crazy).

The FairBoxGenerator uses the standard TRandom.h class of ROOT with a fixed seed. The TRandom.h generator should not be used for statistical analyses, as the following is stated on the ROOT homepage:

TRandom - basic Random number generator class (periodicity = 10**9). Note that this is a very simple generator (linear congruential) which is known to have defects (the lower random bits are correlated) and therefore should NOT be used in any statistical study.

Changing the generator in this class to TRandom3 (Mersenne-Twister) with variable seed (TRandom3(0) ) makes it possible to generate simulations only consisting of particles from the BoxGenerator. How the results (in this case of the invariant mass spectrum) look like with the actual implementation is attached (normally it has not such a spikey structure). Maybe it would be enough to change only the seed, but it is not much more effort to change also the generator. This should also affect those who only embed a few particles with the BoxGenerator in the simulations.

Apart from that this might also be important for everyone who uses a random number generator in his simulations/analyses.


Files

fhPhotons_invmass_cut.png (20.4 KB) fhPhotons_invmass_cut.png Resulting invariant mass spectrum Sascha Reinecke, 07/27/2015 06:44 PM
run_sim.C (18.2 KB) run_sim.C Used macro Sascha Reinecke, 09/07/2015 11:08 AM
fhPhotons_invmass_cut.png (20.6 KB) fhPhotons_invmass_cut.png TRandom3(0) results Sascha Reinecke, 09/07/2015 11:14 AM

Related issues

Related to CbmRoot - Bug #1395: Random RP angle issue with Geant4ClosedVolker Friese10/01/201902/14/2020

Actions
Related to CbmRoot - Bug #2066: Vertex generationClosedDaniel Wielanek03/30/2021

Actions
Actions #1

Updated by Michael Krieger almost 7 years ago

  • Description updated (diff)
Actions #2

Updated by Florian Uhlig over 6 years ago

  • Assignee set to Florian Uhlig
  • % Done changed from 0 to 30

Hi Sascha,

The FairBoxGenerator uses the standard TRandom.h class of ROOT with a fixed seed. The TRandom.h generator should not be used for statistical analyses, as the following is stated on the ROOT homepage:

this is not correct. The FairBoxGenerator does not use the class TRandom. The source file include TRandom.h which is needed for the definition of gRandom which is a pointer to the actually used random generator. If you start a ROOT session and check which random number generator is used by default you will find out that it is TRandom3

demac019:run uhlig$ root -l
root [0] gRandom ->Print();
OBJ: TRandom3 Random3 Random number generator: Mersenne Twistor

I did some checks to verify that the pointer isn't changed while running a simulation and could not find any place in the code (FairRoot and CbmRoot) were the pointer is redefined. I also run a macro putting the print statement from above before and after the run->Init() and after the run->Run() functions. At all three placed the printout shows that TRandom3 is used.

So from my point of view everything looks okay but this doesn't explain your finding with the number of photons.

Could you attach the macro(s) which you have used to generate the strange result. I would like to redo my tests with your macros.

As a side remark.
The basic idea always was that everybody uses the same random number generator which is defined by gRandom. When I checked the code I saw that there are many Instances of Trandom(23) all over the code. This is also something we have to check.

Ciao

Florian

Actions #3

Updated by Florian Uhlig over 6 years ago

  • Assignee changed from Florian Uhlig to Sascha Reinecke
Actions #4

Updated by Sascha Reinecke over 6 years ago

I just use the standard run_sim.C macro with some modifications for input/output filenames and the used generator (UrQMD or Box). (calling macro with run_sim(1000, 4, 1, "", "outputname") )

By explicitly using the TRandom3 generator with seed 0 in the FairBoxGenerator results in a "normal" looking distribution (see attachment)

Actions #5

Updated by Volker Friese about 6 years ago

  • Status changed from New to Assigned
  • Assignee changed from Sascha Reinecke to Florian Uhlig
Actions #6

Updated by Florian Uhlig almost 6 years ago

  • Assignee changed from Florian Uhlig to Sascha Reinecke

Hi Sascha,

how do you produce the plot and what are the parameters passed to the macro?

Actions #7

Updated by Sascha Reinecke almost 6 years ago

I produced the plot by running the simulation + reconstrution + analysis macros in parallel (something like 50 or 100 times) for each time 1000 events and afterwards adding up the output root files from the analysis macro (e.g. with hadd). The data shown in the plot are gained by running my pi0-reconstruction scheme for the simulated data.

The macro call is run_sim(1000, 4, (running number), "sis100_electron", "output"), and accordingly for reco and analysis.
The (running number) is either the SGE_TASK_ID on the cluster or an otherwise running number, when running it on our own machine.

I just saw the same effect a few months ago when again doing simulations with the boxgenerator. Therefore I tried and added the statement "gRandom = new TRandom3(0);" in my simulation macro, which resolved this issue.

Actions #8

Updated by Volker Friese almost 6 years ago

  • Status changed from Assigned to In Progress
  • Assignee changed from Sascha Reinecke to Florian Uhlig
Actions #9

Updated by Volker Friese about 3 years ago

  • Tracker changed from Bug to Sim-Development
  • Project changed from CbmRoot to Simulation
  • Assignee changed from Florian Uhlig to Volker Friese
  • Target version set to OCT19
  • Estimated time set to 10.00 h

Will be picked up for OCT19.

Actions #10

Updated by Volker Friese almost 3 years ago

  • Tracker changed from Sim-Development to Bug
  • Project changed from Simulation to CbmRoot
  • Assignee changed from Volker Friese to Florian Uhlig

Florian, do you have an idea how to proceed in this issue?

Actions #11

Updated by Volker Friese over 2 years ago

  • Due date set to 12/20/2019
  • Target version changed from OCT19 to APR20

To be checked still. Probably connect to #1395.

Actions #12

Updated by Volker Friese over 2 years ago

  • Related to Bug #1395: Random RP angle issue with Geant4 added
Actions #13

Updated by Florian Uhlig over 2 years ago

  • Assignee changed from Florian Uhlig to Ilya Selyuzhenkov
Actions #14

Updated by Volker Friese almost 2 years ago

  • Assignee changed from Ilya Selyuzhenkov to Volker Friese
  • Target version changed from APR20 to APR21
Actions #15

Updated by Volker Friese about 1 year ago

  • Due date changed from 12/20/2019 to 03/31/2021
  • Status changed from In Progress to Closed
  • % Done changed from 30 to 100

Solved with rff6717fe (MR 290).

Actions #16

Updated by Volker Friese about 1 year ago

  • Related to Bug #2066: Vertex generation added
Actions

Also available in: Atom PDF