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!).
Well, what I said about accessing directly CLHEP I meant
in the scope of geant4_vmc, it was just a reaction to your
proposed solution with generating a command. This should
be done, of course, in geant4_vmc and hidden from a user.
So what I proposed to be changed is instead of calling
gRandom->SetSeed(mySeed);
to call:
gMC->SetRandomSeed(mySeed);
So you would stay perfectly within Root framework,
but would use more appropriate object.
Our users simply use
> the gRandom wherever they need to deal with random numbers (of course they
> initialize the proper TRandom in macros).
Calling gMC is as simple as calling gRandom :)
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.
I understand your point, but my experience with mis-using things
is that you are asking for troubles in future.
Ivana
>
>
> 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:
>>> Hallo,
>>>
>>> I think I found avery simple to do that without changing anything!
>>> Simply in the g4Config.C I added the following three lines:
>>>
>>> Text_t buffer[50];
>>> sprintf(buffer,"/random/SetSeeds %i %i "
>>> ,gRandom->GetSeed(), gRandom->GetSeed());
>>> geant4->ProcessGeantCommand(buffer);
>>>
>>> with this our users set the seed as usual using gRandom and this is now
>>> seeted for G4. For those who want to set more complicated things they
>>> have to do it in all cases in the g4config.in or where ever they like.
>>>
>>> regards
>>>
>>> Mohammad
>>>
>>> -----Original Message-----
>>> From: Ivana Hrivnacova [mailto:Ivana.Hrivnacova_at_cern.ch]
>>> Sent: Tue 10/6/2009 10:41 AM
>>> To: Rene Brun
>>> Cc: Al-Turany, Mohammad Dr.; vmc_at_root.cern.ch
>>> Subject: Re: [VMC] Random Seeds in G4_VMC
>>>
>>>
>>> I agree, that it is not a general solution,
>>> but it is working fine with both Root and CLHEP
>>> default generators (maybe with replacement of Long_t
>>> to UInt_t, as TRandom generators get this type
>>> in setSeed), while the current implementation in VMC
>>> does not work.
>>> A clean solution would be to remove
>>> virtual void SetRandom(TRandom* random);
>>> from VMC, as TRandom is not common to all MCs,
>>> and let user to access each random number via
>>> its way (gRandom in case of G3, Fluka and
>>> G4 commands in case of G4).
>>>
>>> Ivana
>>>
>>> Rene Brun 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
>>> a run
>>>>>> 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
>>>>>>>>
>>> --
>>> ==============================================================
>>> e-mail: Ivana.Hrivnacova_at_cern.ch
>>> address: Institut Physique Nucleaire, 91406 Orsay, France
>>> phone: (33) 01 69 15 65 94
>>> ==============================================================
>>>
>
--
==============================================================
e-mail: Ivana.Hrivnacova_at_cern.ch
address: Institut Physique Nucleaire, 91406 Orsay, France
phone: (33) 01 69 15 65 94
==============================================================
Received on Thu Oct 08 2009 - 18:12:35 CEST