Doubt: can you use two generators in one simulation?

I was wondering if it is possible to produce simulations where you send, for example, two photons at the same time from different points. Can you define more than one generator that work simultaneosly? or is there a way to specify that you want to produce two or more primary particles at the same time?

1 Like

Hi Elisa,

it is not yet possible to launch two particles from different positions. The position is associated to the generator itself <generator.

However, it is possible (although still limited) to add several sources to a particular generator. You could for example add two photons adding two <source> definitions, each with its own independent energy and angular distributions.

Those photons would be launched from the same position, or generator. Since the generator is responsible to define from where the primaries will be launched.

If you have a particular application perhaps it is not difficult to add any number of generators to be launched simultaneously or with a given time delay.

What do you really need? As soon as the particles are un-correlated it should not be too difficult. Although it requires some work.


I would like to send two photons at the same time from different points. So, if I understand correctly, for this I would need two different generators, right? Do you think it is easy enough for me to try and change it?

But those photons would be correlated? Which <energyDist and <angulaDist you would use for each photon?

Monoenergetic with the same fixed angle, just produced at different points. They don’t need to be correlated.

If the angle is fixed they have already an angular correlation. The only way now to launch two photons with a fixed angle is using <angularDist type="flux"> so that the direction of both photons are fixed in absolute terms. For example, it is not possible to randomise one photon direction, and launch the second with respect to the random vector of the other photon and a fixed angle.

If launching fixed flux photons in absolute terms is enough for you, then to add an arbitrary number of generators without correlations is a two steps process.

First, the class TRestG4Metadata needs to be updated to read any number of <generator ..> entries. There is an existing method TRestG4Metadata::ReadGenerator. This method could be adapted to receive as argument the generator string string generatorString = GetKEYStructure("generator");

Then, inside the method InitFromConfigFile you need to loop on the generator entries.

Something like …

size_t position = 0;
 while ((generatorString = GetKEYStructure("generator", position)) != "") 
ReadGenerator( generatorString);

All the members filled by ReadGenerator i.e. fGenXX and others without exception should be promoted to std::vector … i.e. gain an additional dimension so that each element of the vector registers the information we are adding now for one generator.

If you fill like taking the step to work on that just create a new branch inheriting from development.

git checkout development
git pull
git checkout -b development_restG4

The second step would be to update the file restG4/src/

I will follow the development and we can discuss it on the Gitlab site.

1 Like

Thank you very much, Javier!

I don’t need to randomise the direction, so using the flux option may work for me. I just need to launch them parallel in the same direction that can be fixed e.g. (0,0,1)

I can try to implement this modifications, thanks for the insight! I’ll follow the git steps and let you know :slight_smile:

Ok, for that scenario proceeding with multiple generators looks as a good solution.

I just though on an alternative option. There is also the possibility to write a generator file. We use for example Decay0 pre-generated files as input for a NLDBD generator, so that we define the correlations on momentum and energy between the two electrons.

It looks like, from that the FILE type is able to launch particles from different positions.

    for (int j = 0; j < nParticles; j++) {
        if (generator_type == g4_metadata_parameters::generator_types::FILE)  // Generator type "file"...
            // ...Get position from particle collection

So, perhaps it is possible to produce a generator file externally and use it as a generic case? The problem is that the Decay0 format does not specify relative positions for each particle, but the code seems to accept different positions. Perhaps @nkx could give more light on this alternative.

Maybe we can take advantage of TRestParticleCollection? just like restDecay0 package, which adds a class TRestParticleCollectionDecay0 as custom generator. Not only can we set particles’ direction inside it. We can set their positions together.

Yes, to implement a class similar to TRestParticleCollectionDecay0 for this particular case would also be a good example. Probably more elegant.

The use key will be used to define/construct the name of the class generator model to be used. For instance use="decay0" will produce TRestParticleCollectionDecay0, or use="mymodel" would produce TRestParticleCollectionMymodel.

In the particular case of decay0, the parameters particle, decayMode and daugtherLevel are retrieved inside InitFromConfigFile from that class, and help to customise the generator.

<source use="decay0" particle="Xe136" decayMode="0vbb" daughterLevel="3" />

If you develop a dedicated class to implement a custom defined generator, namely, You could make anything you want with the positions and directions of the primary particles inside your class, in a similar way as it is done inside TRestParticleCollectionDecay0. I imagine, the method VirtualUpdate it is used in the loop at PrimaryGenerator to allow to randomise, select different particle properties, position, direction, etc, at each event.

Then, you would do something like (just an example)

<source use="faser" pos1="(x1,y1,z1)" pos2="(x2,y2,z2)" />

where pos1 and pos2 are parameter that you define inside the class TRestParticleCollectionFaser as desired in order to customise your generator from the <source metadata entry.

In that case, I imagine the <generator spatial definition will be ignored. @nkx I am right?

The spatial definition in <generator should be updated to type: “file”, I guess.

Previously when we use decay0 generator file, we set the particle’s position from “volume” named “Gas”:

    <generator type="volume" from="Gas" >
      <source use="Xe136bb0n.dat">

To use custom generator with custom position, It will be:

    <generator type="file">
      <source use="faser">

Those keywords are really confusing. I looked into the code and found that “file” means to use the position from particle’s self data. “volume” and others means to radomize a position and assign to the particle.

Maybe in future we shall update the format, changing to some better comprehensive words.

Not only improving the format. I think this might be a problem. Because I am allowed to define something like

    <generator type="file">
      <source use="decay0">


    <generator type="volume">
      <source use="decay0">

I guess, in the case of custom user defined generators we should not define any generator type, and when we identify in the code that it is custom defined then force/overwrite fGenType.

     info << "Load custom sources from " << use << endl;
     TRestParticleCollection* particleCollection = TRestParticleCollection::instantiate(use);


I would prefer to change the name of fGenType="file" by something as fGenType="custom". Probably this would require some updates at PrimaryGeneratorAction.

1 Like

Hello! I have been also trying to generate more than one particle in each event. In my case, generating the same position is not a problem. I have tried adding two definitions inside the . Nevertheless, I get the following error:

TRestGeant4Event: Number of particles on primary vertex does not match number of sources for event ID: 0

Is it possible to set the generated number of particles from the .rml file or is it necessary to modify the libraries?

Hi @JaimeAA this is a very old post, the best is you create a new post giving more details on the problem.

Give details on the particles you want to generate, share the example you are running for others to reproduce the issue you are having.

Please, create a new post, attaching the RML or copying/pasting the relevant parts.

If this post is relevant to you, you can always give a link to this post in the new post.

Yes, I will do it, thanks!