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).
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
#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.
#8 Updated by Florian Uhlig about 2 months ago
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.
#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.