Hi Ivana,
Thanks for this change, and may be we can discuss about possible improvements at the VMC meeting end of this month.
Regards,
Mohammad
On 10/13/09 12:27 PM, "Ivana Hrivnacova" <Ivana.Hrivnacova_at_cern.ch> wrote:
> > Hi Mohammad, > > As there was no agreement on eventual improvement of > this feature in VMC, I implemented passing the random number seed > from gRandom to G4 random number generator. > The update is now in SVN trunk. > > Regards, > > Ivana > > Mohammad Al-Turany wrote: >> Hallo Ivana, >> >> I understand your point, but in our special case (FairRoot) we use root >> macros to steer our simulation, reconstruction and analysis, and all our >> code is root based, so I do not want to touch or see the CLHEP things in a >> steering macro (I am not sure if I even can do this!). Our users simply use >> the gRandom wherever they need to deal with random numbers (of course they >> initialize the proper TRandom in macros). So what I do here is simply to >> miss-use in some way the gRandom to set the seed in the steering macro in a >> unified way, which is then in case of G4 just get read again in the G4 >> configure macro. So tell we have a proper interface to the different random >> generators this solution make my life easier. >> >> >> Regards >> >> Mohammad >> >> On 10/8/09 5:26 PM, "Ivana Hrivnacova" <Ivana.Hrivnacova_at_cern.ch> wrote: >> >>> Hi Mohammad, >>> >>> You can, of course, get the seed from gRandom >>> and pass it to Geant4 (even in a more simpler >>> way, as you can access directly the CLHEP random >>> generator via its static methods), >>> but I wanted to avoid going through gRandom, >>> as it has nothing to do with Geant4 random >>> number generator. >>> >>> And at the end, what we try to do is just to >>> pass a seed value, that's why, as a more appropriate >>> interface, it seems to me to interface just this >>> action, without going through a global object. >>> >>> Regards, >>> >>> Ivana >>> >>> Al-Turany, Mohammad Dr. wrote:
>>>>> This is not good because random number classes may have a seed that is >>>>> an int, a longlong or an array. >>>>> >>>>> Rene >>>>> >>>>> Ivana Hrivnacova wrote: >>>>>> I think much simpler, and more transparent to the user >>>>>> would be to change the current TVirtualMC function: >>>>>> virtual void SetRandom(TRandom* random); >>>>>> to >>>>>> virtual void SetRandomSeed(Long_t seed); >>>>>> >>>>>> Ivana >>>>>> >>>>>> >>>>>> Mohammad Al-Turany wrote: >>>>>>> Hallo Ivana, >>>>>>> >>>>>>> Ok, I agree it is more complicated than what I expected! But all what >>>>>>> I want >>>>>>> is to be able to set the seed myself in a consistence way, without >>>>>>> really >>>>>>> caring which random generator is running behind. >>>>>>> >>>>>>> So what about implementing something in the init of VMC which simply >>>>>>> put the >>>>>>> gRandom::GetSeed() in an ASCII (current.rnd) file that is read by >>>>>>> default in >>>>>>> the g4config.in with >>>>>>> >>>>>>> /random/resetEngineFrom current.rnd >>>>>>> >>>>>>> And for the advanced users who would like to restore or re-process
>>>>>>> they have to change the config.in. But at least for the normal use >>>>>>> one has >>>>>>> the control over the random seed whatever generator is setting behind, >>>>>>> because originally we had the problem with G4_VMC that it always uses >>>>>>> the >>>>>>> same seed and that is way we need to control it specially on the grid >>>>>>> and >>>>>>> batch farms. >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Mohammad >>>>>>> >>>>>>> >>>>>>> On 10/5/09 11:33 AM, "Ivana Hrivnacova" <Ivana.Hrivnacova_at_cern.ch> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Mohammad, >>>>>>>> >>>>>>>> Geant4 does not use the random number generator from Root, >>>>>>>> but from CLHEP, that's why I considered it as misleading >>>>>>>> to implement setting its seed via gRandom. >>>>>>>> >>>>>>>> The reason is that this way would not allow you >>>>>>>> to re-process a run or event from a previous simulation >>>>>>>> by storing gRandom status and restoring it in a new >>>>>>>> simulation, as gRandom status has nothing to do with >>>>>>>> the random generator used by Geant4. >>>>>>>> >>>>>>>> The command >>>>>>>> /random/resetEngineFrom current.rnd >>>>>>>> should be used together with a file stored via Geant4 >>>>>>>> commands >>>>>>>> /random/saveThisRun >>>>>>>> /random/saveThisEvent >>>>>>>> If you try the command and look at the file, you >>>>>>>> will see that there is more data than just one long number. >>>>>>>> >>>>>>>> You can use gRandom->GetSeed() (=mySeed) number for setting >>>>>>>> initial seed: >>>>>>>> /random/setSeeds mySeed mySeed >>>>>>>> (G4 setSeeds requires at least two long values) >>>>>>>> but a question is what it will be good for. >>>>>>>> >>>>>>>> A possible solution to handle the different random generators >>>>>>>> in a common way via VMC could be to interface the appropriate >>>>>>>> functions for storing/restoring the generator status. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Ivana >>>>>>>> >>>>>>>> >>>>>>>> Mohammad Al-Turany wrote: >>>>>>>>> Hallo, >>>>>>>>> >>>>>>>>> As you all know to set the Random seed in G3_VMC it is enough to use >>>>>>>>> gRandom->SetSeed(seed), in G4_VMC this does not work, and what I >>>>>>>>> do to >>>>>>>>> set the seed is to go via the g4config.in macro and put there: >>>>>>>>> >>>>>>>>> /random/resetEngineFrom seed.rnd >>>>>>>>> >>>>>>>>> Where seed.rnd is an ASCII file containing my seeds. >>>>>>>>> >>>>>>>>> Is it possible to unify this behavior and to pass the seed from >>>>>>>>> gRandom >>>>>>>>> to the G4_VMC in the initialization? Or do you have any other >>>>>>>>> suggestion? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Mohammad >>>>>>>>>
-- Dr. Mohammad Al-Turany IT Department Gesellschaft für Schwerionenforschung mbH Planckstraße 1 D-64291 Darmstadt Limited Liability Company Registered Office: Darmstadt, Commercial Register: Darmstadt, HRB 1528, Managing Director: Professor Dr. Horst Stöcker Supervisory Board Chair: Dr. Beatrix Vierkorn-Rudolph, Deputy Chair: Ministerialdirigent Dr. Rolf BernhardtReceived on Tue Oct 13 2009 - 12:34:11 CEST
This archive was generated by hypermail 2.2.0 : Fri Nov 06 2009 - 17:25:01 CET