Bug #2066

Vertex generation

Added by Daniel Wielanek about 2 months ago. Updated 13 days ago.

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


Spent time:


Dear Volker,
I think that there is problem with seed of vertex position. I tried to make some large productio. I run transport.C macro and noticed that for each of file the vertex position of first event is always the same (I'm not sure why for other events (not first in thefile) the vector position is random).
I suppose that this might be fixed but gRandom->SetSeed(seed) in transport macro (I'm already checking it).

vertex.png View (75.9 KB) Daniel Wielanek, 03/30/2021 08:54 PM

Related issues

Related to CbmRoot - Bug #337: FairBoxGenerator (maybe not only there): random number generator Closed 07/27/2015 03/31/2021
Related to Simulation - Sim-Development #1903: Add random number to the run/run_transport_beam.C Resolved 11/16/2020

Associated revisions

Revision ff6717fe (diff)
Added by Redmine Admin about 2 months ago

Set random seed when running a simulation

Up to now the ROOT random number generator was always initialised with the
same default value. In some cases this gives strange results when doing
large scale simulations with several jobs.
To solve the problem TRandom is now initialised with the value 0 which uses a
seed value based on the system time with a granularity of 100ns.
This granularity should be good enough to have different seed values even if
several jobs start a similar times on the batch farm.
A setter was added to allow to set the seed value explicitly from a macro,
refs #1395, #2066


#1 Updated by Volker Friese about 2 months ago

That can well be. Probably the vertex position is the first random number to be taken from gRandom. Then, if the seed is the same, the value will also always be the same.

As you pointed out, this can be avoided with explicitly setting a random seed.

#2 Updated by Daniel Wielanek about 2 months ago

This might be very stupid, or very important question - but did somebody check the mass production vertex?

#3 Updated by Volker Friese about 2 months ago

  • Status changed from New to In Progress

I hope that in mass production, a proper random seed is set for each run / file. Otherwise, we have more problems than just the event vertex. Ilya and the PWGs should comment.

#4 Updated by Oleg Golosov about 2 months ago

This has been already discussed in #1395.
Almost a year has passed but users keep facing this issue and loosing time and effort on their own investigations.

Is there any reason that prevents us from setting seed of gRandom to zero by default?
This could be easily done either in compiled code (e.g. CbmTransport class) or in example macros and prevent the problem from reappearing any more.

PS: The issue is not relevant for the common productions because I seeded gRandom with zero in the transport macro.

#5 Updated by Florian Uhlig about 2 months ago

Hi Oleg, Hi Volker,

please check the linked merge request which should solve the issue. gRandom will be initialised with a value when setting up the simulation. As default the value is 0 but can be set also from the macro to any other value. If you agree to the fix please approve the MR.

#6 Updated by Florian Uhlig about 2 months ago

  • % Done changed from 0 to 50

#7 Updated by Oleg Golosov about 2 months ago

Thank you, Florian, the fix is perfectly fine.

It is stated in the merge request that "No approval required" so I cannot approve it on GitLab.

#8 Updated by Florian Uhlig about 2 months ago

Hi Oleg,

since you are now developer in the project you can't click approve button but you can create a comment with your approval or you can click on the "Thumbs up" button which I would also count as approval. But also your comment here is fine with me.

#9 Updated by Pierre-Alain Loizeau about 2 months ago

Sorry for the late intervention.


grep -rn --exclude-dir build "gRandom->SetSeed" *

shows that the seed setting is mostly done in the macros for the time being (sometimes with 0, sometimes with hardcoded values, sometimes with a macro parameter).
Won't the proposed change break this by overriding the values if the macros are not updated?

I would propose that an email/news is used to warn users that they may have to update their XXX_sim.C macros, as the fix is probably a simple move of the value to the new setter added by Florian and a remove of the explicit "gRandom->SetSeed" call.

(Some obsolete macros may even end up cleaned out instead of updated, for example in the macro/tof/qa folder, which could be good)

#10 Updated by Florian Uhlig about 2 months ago

This is not an issue. I have checked the macros which of them uses the CbmTransport class and set the random seed and I didn't find any. Most macros which uses gRandom->SetSeed() are for construction of geometries. There are probably also some other ones but I don't care too much since they have to be fixed by the developers.

I think in near future we should try to run the macros and remove macros which do not work out of the box. If they are needed they have to be brought back by the developers together with a nightly test.

#11 Updated by Volker Friese 17 days ago

  • Related to Bug #337: FairBoxGenerator (maybe not only there): random number generator added

#12 Updated by Florian Uhlig 17 days ago

  • Status changed from In Progress to Resolved
  • Assignee changed from Volker Friese to Daniel Wielanek
  • % Done changed from 50 to 100

Since the issue is fixed with MR 290 I change the state to resolved.

Daniel could you please check and close the issue if your problem is gone.

#13 Updated by Daniel Wielanek 13 days ago

  • Status changed from Resolved to Closed

It seems to work, so I'm closing issue.

#14 Updated by Volker Friese 12 days ago

Also available in: Atom PDF