Is it possible to do optical simulations with RestG4?

[girardcarillo]

This issue is related to this post on the forum: https://rest-forum.unizar.es/t/is-it-possible-to-do-optical-simulations-with-restg4/589

Summary of the discussion on the forum: I wanted to know if it was possible to perform optical simulations with restG4. Apparently it's not (yet?) possible.

In that case, is it possible to perform the optical simulations with Geant4 and then link Geant4 to REST, without using RestG4? I think it's possible because of what I understand, restG4 is just a package, that you can decide to use or not. But I've never done it. And the question remains: the data format of the simulation output files would still be different that the one for "classic" particle/matter RestG4 simulations no?

Thanks, Cloe

[jgalan]

I think the best would be to think a way to integrate the optical simulations into restG4. There are a number of people interested on this topic. I will add them to the assignees. We will probably discuss this next week in Zaragoza. We can keep the thread active here.

[lobis]

Some things to keep in mind:

• "regular" radiation photons (gamma) and optical photons are different particles in Geant4.
• Optical photons can interact with volumes (attenuation) and surfaces. restG4 is not aware of surfaces. They can be defined in the gdml in different ways.
• A few optical properties need to be defined: refraction indices (for different photon energies), scintillation yield, surface type (flat, rough, etc.)
• rest-for-physics aims to preserve the full information of the event as much as possible (basically serializing the geant4 event into disk). This is not practical when you introduce optical photons: too many are typically produced, there would be too many tracks. We would need a way to remove the tracks but preserve its information.
• We probably need a "sensitive optical surface" concept which tracks optical photons that reach it. (which typically wouldn't be stored in disk). Right now everything revolves around sensitive volume energy (is file saved? etc.), we would need to accomodate this "number of photons in optical surface" as an alternative (do we care about the energy of these photons?).

[jgalan]

Another thing to keep in mind:

• Which information can be generated by restG4 and which information could be processed further later on, at a particular library? E.g. at geant4lib or at detectorlib?

[juanangp]

I think that to implement optical simulations in rest-for-physics would an asset for the software, but I think that to do it inside restG4 will have many drawbacks:

• I guess optical simulations takes a lot of time an resources because as far as I understand Geant4 tracks every single optical photon, so the simulations that we typically performed using restG4 will take forever. Do we really need to perform the optical simulation for every single event? I would say that for a LiquidO simulations we just need a parametrization of the optical signal rather than a full simulation.
• Also, as some of you point out, it will be difficult to understand which information needs to be stored, for instance I would like to know the underlying processes before the generation of optical photons, e.g. the same output that we have now in geant4lib.

So, I think that an optical simulation will be useful to parametrize the optics for a particular geometry or readout, but I think that doesn't make sense to implement a full optical simulations inside restG4 . So, I propose the following:

• Create a new package or program for a dedicated optics simulation e.g. restG4Optics or so, but focused on optical simulations. This new package can take as input any simulation carried out using restG4 and just perform the optical simulation. Since there are many things in common with the restG4 package like the geometry perhaps we can reshuffle the code and put the common things together and just implement restG4Optics inside restG4 package? @lobis can you comment on that? I am not familiar with this part of the code.
• Create a new class container TRestGeant4OpticsEvent for the optical simulations, perhaps it can be implemented inside geant4lib? Then we can decide which information and the format of the optical simulation results that need to be stored.
• Create new processes in rest-for-physics to parametrize the optical simulations, then we don't need to run the optical simulation for every single energy deposit. In fact, I have been working on this topic and I can give a hand on that, but unfortunatelly I don't have time to work more on it till mid December.

With this approach we can keep using restG4 in the same way that we are doing know preserving all the information of the energy deposition, while the optical simulation can be done later on using restG4Optics, so we can keep track of the underlying processes. Also, I think that we should have the possibility to parametrize the optical simulation (as we are doing with the diffusion) to speed up things.

[lobis]

I think that to implement optical simulations in rest-for-physics would an asset for the software, but I think that to do it inside restG4 will have many drawbacks:

• I guess optical simulations takes a lot of time an resources because as far as I understand Geant4 tracks every single optical photon, so the simulations that we typically performed using restG4 will take forever. Do we really need to perform the optical simulation for every single event? I would say that for a LiquidO simulations we just need a parametrization of the optical signal rather than a full simulation.

You can have full control of this inside Geant4. Send the optical photons to a lower priority stack drop them if some condition isn't met (energy in sensitive volume, etc.). This would work for instance for the optical simulations for the veto scintillators (you only want to do it if there is energy in the sensitive volume).

• Also, as some of you point out, it will be difficult to understand which information needs to be stored, for instance I would like to know the underlying processes before the generation of optical photons, e.g. the same output that we have now in geant4lib.

Having the full event (optical + non-optical) as a single object would be my choice, this way it's easier to do the analysis. There would be some problems I guess, perhaps we need to track additional members for the optical photons (surface + volume?) but I think it's doable.

So, I think that an optical simulation will be useful to parametrize the optics for a particular geometry or readout, but I think that doesn't make sense to implement a full optical simulations inside restG4 . So, I propose the following:

• Create a new package or program for a dedicated optics simulation e.g. restG4Optics or so, but focused on optical simulations. This new package can take as input any simulation carried out using restG4 and just perform the optical simulation. Since there are many things in common with the restG4 package like the geometry perhaps we can reshuffle the code and put the common things together and just implement restG4Optics inside restG4 package? @lobis can you comment on that? I am not familiar with this part of the code.

I am not sure about this. I think it would be too tightly coupled to restG4 that splitting it as a separate package would be detrimental. It would require significant effort to refactor restG4 so the common code can easily be used by both.

• Create a new class container TRestGeant4OpticsEvent for the optical simulations, perhaps it can be implemented inside geant4lib? Then we can decide which information and the format of the optical simulation results that need to be stored.
• Create new processes in rest-for-physics to parametrize the optical simulations, then we don't need to run the optical simulation for every single energy deposit. In fact, I have been working on this topic and I can give a hand on that, but unfortunatelly I don't have time to work more on it till mid December.

With this approach we can keep using restG4 in the same way that we are doing know preserving all the information of the energy deposition, while the optical simulation can be done later on using restG4Optics, so we can keep track of the underlying processes. Also, I think that we should have the possibility to parametrize the optical simulation (as we are doing with the diffusion) to speed up things.

I don't know what would be the best way to approach this. To be honest if we were to make a new package for this we might as well make "restG4 v2" to overcome the limitations of the current restG4 and make it do both types of simulations. restG4 currently works but it's hard to build on it. But I think this would be a different discussion