About the source Time and Frequency

Particles, Track, Event, Run and Biasing
1

Hello everyone ,
currently i’m trying to run a simulation with a source of particles (e-), which i want to customize as following steps, pulses of 1 us width and frequency of 100 Hz,
I have look up to many doncumentation, nothing was found to reggarding the frequency and pulses duration on GEANT4.

2

Geant4 doesn’t operate that way. Each event is a separate entity, caused by one incident particle, like an electron. If your readout system is slow enough that each of your 1 us pulses appears as “one event”, then you can generate N primary electrons and have them all interact in the same event.

If you wanted to get really fancy, you could write your own custom PrimaryGeneratorAction, throw a random time (flat, Gaussian, whatever you like) in a window from 0 to 1 us, and assign that time to one of the N primary electrons. If you record the time of hits via your SD into an N-tuple, then you can look at temporal distributions in your analysis.

As for the pulse frequency, Geant4 neither knows nor cares about that. It knows and reports the number of events you generated. You need to translate that into real world information (number of pulses, incident dose/energy, whatever).

3

thank you mkelsey for your replay,
when i didn’t found anything related pulses or time frequency, i expected that geant4 doesn’t operat like that, so if i get it write, i can creat PrimaryGeneratorAction with radom distribution by specifing a time window (even i don’t know how to do it) and assign it to the primaries , and for the frequency how can translate the events to inciden dose for example .

4

In Geant4, you can set a time_zero to an event.
See examples/extended/radioactivedecay/Activation : PrimaryGeneratorAction.cc, line 105

1 Like
5

Thank you maire for the seggustion,
bassicaly my goual is to acheave higher doses, thats why i want to deliever primeries into pulses, with highier frequency, i can do it with geant4 ,???

6

Hej,

since there is no concept of pulses/intensity in Geant4, we only know event-by-event, what you can do is to add a time profile to your initial particles which then you can store and use at a later stage in analysis to group them together and get what you want.

7

hello Pico, thank you, My appreciation, could you please elaborate more on how I can do it, an example which adapting similar things

8

So, I’ m thinking something as follows:

  • Running the simulation where your primaries have a defined time structure, something like: 3 primaries with starting time 0s, 1 particle with starting time 1s, 3 particles with starting time 2s, … this in a sense mimics a “pulsating” source
  • Store the hits/digits into a outfile file, CSV, ROOT, etc.

Once you are done with the simulation you can analyze the stored hits in the output file, something like:

  • read the hits one-by-one. By construction we made them in ascending time order so this is easy.
  • if the time of the hits is within 1s (for this example) they belong to the same pulse and can be threated as such, maybe added them together, or whatever else you have in mind like producing a picture.

Creating your own time profile is relatively simple using the ParticleGun. If you use the General Particle Source you can sample for time profiles… in this case however the output file will not be time ordered so an additional step of time ordering the output file might be needed.

Have fun,

/Pico

1 Like
9

Hi, @pico
Sorry for pooping this old thread.
Can you please share more details on how to sample sources for time profiles using GPS .

I have two primary ammas per event set using /gps/num. I am trying to provide a random distribution to each such that gamma1(gamma2) has a time distribution about a mean m1(m2).

Sorry if this is too naive; I was reading the various macros but could not find much except /gps/time, which I think set the same time for the event and hence for both gammas.

Thanks a ton !

10

Hello @kitu.utkarsh ,

this is how I modify their initial time. I am unsure but I think this would work even if you define more than one vertices.

PrimaryGeneratorAction::PrimaryGeneratorAction()
    : G4VUserPrimaryGeneratorAction(),
      fParticleGun(nullptr)
{
  fParticleGun = new G4GeneralParticleSource();
  rate         = 0 * hertz;
}

void PrimaryGeneratorAction::GeneratePrimaries(G4Event* anEvent)
{
  G4int    evn_ctr = anEvent->GetEventID();
  // check if I defined a rate or not and set its initial time accordingly
  G4double time    = rate != 0 * hertz ? (G4double)(evn_ctr / rate) : 0;
  fParticleGun->SetParticleTime(time);
  fParticleGun->GeneratePrimaryVertex(anEvent);
}

Let me know whether it works

/Pico
1 Like
11

Hi @pico,

Thanks a lot for your prompt reply and for sharing the detailed method.

Yeah, I am defining only one vertex with two primary particles, so I will try to extend it for my case.

One more silly question: how are we specifying (in the code snippet above) which time is assigned to which particle? For example, for a vertex comprising of two primary particles, one particle with a starting time of t1 sec and a second particle with a starting time of t2 sec

12

Say you have a frequency of 2Hz and one vertex:

  • the particle for the first event will have a time 0.0s
  • the particle for the second one will have 0.5s
  • the particle for the third one will have 1.0s
  • …

My guess is that ALL the particles from the different vertices will have the same initial time.

In postprocessing you can check if there are secondaries produced by the particle starting at 0.0s that perhaps decayed (or something) at a later time, say 1.5s and therefore they SHOULD have been detected in coincidence with the particle(s) that started at 1.5s.

1 Like
13

Thanks for the super clear explanation.

Oh, I see. I was confused initially; I thought the particles in one vertex would have different initial times.

So essentially, if I understand right, by default the initial time of each event is reset to 0 ns.
In the above code, we are setting the starting time of each event(and all the primaries produced therein) to be sequentially increasing with respect to that of the preceding last event.

Please correct me if I am wrong.

14

Correct. We are offsetting the start of the GlobalTime

15

Thanks for your reply.