Implementing CRY generator as a new source inside TRestGeant4ParticleSourceCry

[jgalan]

The following PR implements an interface to CRY generator that can be plugged to restG4. All the access to CRY libraries is inside the class TRestGeant4ParticleSourceCry, which has been inspired on TRestGeant4ParticleSourceDecay0.

The class allows to configure/setup the CRY generator and it implements a method to update the particles for each event.

This PR requires minor contributions to restG4 and framework repositories.

• Inside restG4 we simply include an example to test the generator CryGenerator.rml, and we introduce minor modifications inside PrimaryGeneratorAction so that when we use <generator type="cry" ... > the position of the particle is fixed using the CRY generator positions. Implementing the CRY generator into restG4 restG4#121.

• Inside the framework we need to add the library CRY inside thisREST.sh so that executables will be able to find the library path. Adding CRY to LD_LIBRARY_PATH inside thisREST.sh framework#489

---

In order to link the CRY libraries to libRestGeant4 we need to generate the shared object from the static library libCRY.a.

This can be done with the following command:

gcc -shared -o libCRY.so -Wl,--whole-archive libCRY.a -Wl,--no-whole-archive

---

Once we have generated the libCRY.so we need to compile REST with the new option.

cmake -DREST_G4=ON -DREST_CRY_PATH=/path/to/cry/main/directory/

And we can use the new example added to restG4.

cd source/packages/restG4/examples/12.Generators/
restG4 CryGenerator.rml

10 events will be generated in this example, stored in the output file CryGenerator.root. We can open to inspect:

restRoot CryGenerator.root

And access the new particle source generator metadata:

And check the generator events:

In the previous image we can see how the CRY generator has produced an electron and a neutron.

The event header contains also the source position, but only the one for the first (or last) particle. This is redundant information, but incomplete, since we need to really look to the tracks to understand what are the particles produced by the generator. Perhaps it would be better to remove those fields from TRestGeant4Event? @lobis?

I have seen that TRestGeant4ParticleSource defines PrintParticleSource but perhaps this should be migrated to PrintMetadata? @nkx111

I let @Jaime-AA to play around and validate the generator.

I was surprised that when I define altitude = 2100m, the particle is still produced at z=0, I guess one needs to use zoffset so that the particles are generated at that altitude.

[nkx111]

Maybe it's interesting to add a new class like TRestGeant4ParticleSourceDecay0 that can generate muons during simulation?

[jgalan]

Maybe it's interesting to add a new class like TRestGeant4ParticleSourceDecay0 that can generate muons during simulation?

The present implementation will do exactly that using the CRY generator.

So, I don't understand, what do you mean? You mean the present cosmic generator implemented inside PrimaryGeneratorAction inside restG4 to be transferred to something like TRestGeant4ParticleSourceCosmics?

[nkx111]

So, I don't understand, what do you mean? You mean the present cosmic generator implemented inside PrimaryGeneratorAction inside restG4 to be transferred to something like TRestGeant4ParticleSourceCosmics?

Yes! Actually there was a naming convention that when you want to add external generators the class name should be TRestGeant4ParticleSourceXXX, where XXX is the name of the generator.

From my point of view, CRY(and also decay0) is just a random number generator. That is, every time you call a certain method, it will randomize the energy and angle of a particle according to the muon spectrum. Those information can be well kept in TRestGeant4Particle, which can be passed to restG4 with common code in PrimaryGeneratorAction.

I was surprised that when I define altitude = 2100m, the particle is still produced at z=0, I guess one needs to use zoffset so that the particles are generated at that altitude.

I guess the altitude only changes the muon energy distribution. In any case your simulation origin is not necessarily same as your lab altitude. Perhaps we need to add some options inside rml, such as the lab altitude, longitude and latitude. We may also need a definition of source volume (normally in muon simulation we set the particles to be generated from a very large horizontal plane above the detector)

[nkx111]

I have seen that TRestGeant4ParticleSource defines PrintParticleSource but perhaps this should be migrated to PrintMetadata? @nkx111

Yes, this shall be OK.

[jgalan]

We may also need a definition of source volume (normally in muon simulation we set the particles to be generated from a very large horizontal plane above the detector)

Actually I think it is the CRY generator the responsible to do this. It is generating particles in a 2-dimensional box with dimensions subboxLength and at a position given by zoffset.

Those values can now be updated in the RML, they are metadata members of the generator.

[jgalan]

One last thing that needs to be integrated is the random generator seed. It is always producing the same sequence.

[Jaime-AA]

The REST implementation works correctly. The only thing is that I had to generate the shared library of CRY using objects created with the -fPIC flag (something about the CRY installation)