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
==============================================================
Received on Tue Oct 06 2009 - 10:41:32 CEST