Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrating optical photons into restG4 #124

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

Conversation

mariajmz
Copy link

@mariajmz mariajmz commented Nov 30, 2023

mariajmz Ok: 32 Powered by Pull Request Badge

This PR is related to the Issue #123.

I added G4OpticalPhysics list to PhysicsList and included the optical surfaces headers to the DetectorConstruction class as first stage to include optical photon simulations in restG4.
Also, I needed to update TRestPhysicsList::PhysicsListExists, which I have done in PR rest-for-physics/geant4lib#119.
So, to include optical physics in a restG4 simulation, just add <physicsList name="G4OpticalPhysics"></physicsList>

I have checked the simulation of Optical Boundary processes in restG4 (ie, reflection, refraction, absorption) with two basic geometries:

  • The first, a gold layer as an xray mirror. Assigning refraction indexes and optical surfaces (dielectric_metal) via gdml.

An example of an absorbed photon:
event_mirror_abs
And a reflected photon:
event_mirror_reflect

In this case, the red volume doesn't have refractive index so the optical photons are killed when they reach it.

The optical photon generator is configured via rml just using <source particle="opticalphoton">. Also, G4OpticalPhoton have polarization. This has not been implemented so, while running the restG4 simulation with debug verbose level, you will see this message:
polarization_msg

As Optical Boundary processes are classified as 'Transportation' in GEANT4, all of the hits have processName 'Transportation'. Maybe it will be interesting to save more specific information of the hit (if it is refraction, reflection or absorption in dielectric_metal surfaces). As I undestood and did in GEANT4, for Optical Boundary processes this needs to be done differently, checking G4Step::GetPostStepPoint()::GetStepStatus(). Maybe @lobis,@jgalan have some ideas about this?

I haven't include the gdml and rml of these examples into this PR, just tell me in case you believe it's necessary.

@mariajmz mariajmz linked an issue Nov 30, 2023 that may be closed by this pull request
@mariajmz mariajmz changed the title Mariajmz optical Integrating optical photons into restG4 Nov 30, 2023
@mariajmz mariajmz added the geant4-compatibility Remove deprecated interfaces or support new ones label Nov 30, 2023
@lobis
Copy link
Member

lobis commented Nov 30, 2023

Looks good to me!

This is a good first step towards full-stack optical simulations.

Regarding storing additional step information instead of just Transportation, I think the process could instead be replaced by the more informative Reflection, etc. Not sure if this has some limitations.

I would like a more general solution to this problem. For example for hadronic processes such as nCapture (neutron capture) it's interesting to know which isotope actually captured the particle. This information is also available in Geant4, however there is no place to store it in the current layout for the event data. We could just add a new field to the hits for each one of this needs but it would be too ineficient as it would be mostly empty for all hits (root compresses de data on disk, but this compression is not perfect). But this is a different issue, for now, storing it in place of the process should be enough, I guess.

By the way the link to the Geant4Lib PR is broken.

Also currently as it stands (I think) this PR is linked to the "big issue" #123 which has a larger scope, if this is merged, that issue will be closed and we don't want that, not until more features are added, examples and documentation included, etc.

@mariajmz
Copy link
Author

Thank you @lobis! I fixed the link to the geant4lib PR.

So should I unlink this PR to issue #123?

@lobis
Copy link
Member

lobis commented Nov 30, 2023

So should I unlink this PR to issue #123?

Yes, it's enough to mention it. Linking the issue will close it when this PR is done and we don't want that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development geant4-compatibility Remove deprecated interfaces or support new ones
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants