Somehow special optical properties can increase signal by a factor of 12-14 for one electron

[cameronc137]

Running the beam generator and shooting an electron at a piece of quartz (as defined in https://github.com/JeffersonLab/remoll-detector-generator/blob/f96be983575277f8f95826ccf0b799845ff824ac/materialsOptical.xml#L32) registers 13 or 14 hits of the exact same particle. While shooting the same generator at a ideal vacuum detector with no interesting optical properties only registers 1 hit. Changing the material of that same vacuum detector to quartz replicates the 13 fold electron count increase. And this increase is reflected in the optical photon counts on another nearby detector, which is probably due to the same 13 fold increase comping from optical properties on the detector.

It is likely that the issue comes from the optical properties behaving in a strange way, but the documentation for these things is very sparse, so I will keep track of progress and any suggestions or solutions here.

https://github.com/JeffersonLab/remoll/blob/51357b4f8a5ea3eff3ae88df8f379e07b7b354e7/src/remollGenericDetector.cc#L155

[wdconinc]

This is how Geant4 works (sorry if it's repetition). It takes steps. The length of the step is determined by the typical interaction lengths of all processes the track can undergo.

• electron in vacuum: not many processes, long interaction length, long steps, typically 1 step in a detector volume of ~cm thickness
• optical photon in optical material: short interaction length, short steps, typically a step per mm of track length, and of course if it keeps bouncing around it accumulates

So, yeah, you should plan for more than 1 hit by optical photons in active volumes.

Could that be causing it? I.e. is this just expected behavior?

[wdconinc]

Typical workaround for charged particle detectors: only store the hit when you enter the volume (with geomboundary).

That doesn't work here because Cerenkov photons are generated inside the volume already. There is typically no geomboundary crossing that we can use to tag interesting hits.

[cameronc137]

Interesting. I thought the hits were only registered when the particle entered the logical volume, but I guess this makes sense too.

This would explain the 13 fold excess of electron hits inside the quartz block, but it doesn't explain the same similar factor of excess of optical photons hitting the very thin cathode at the end of the light guide.

[wdconinc]

@cameronc137 Can you revisit this bug report with the #127 bugfix-opticalProperties branch? If you think there's no issue, can you please close. If you think there is, can you explain again?

The main problem here is, I think, that we should really not be storing optical photons but only photo-electrons. Storing optical photons hits only when entering a volume are useless (we'd just get a couple of them on generation by the Cerenkov or scintillation processes), storing them at every step blows up the files enormously since their mean free path in air is so short, and storing them when leaving the volume is useless as well. When do we care about them? Only when they convert into a photo-electron at a photo-cathode.

Anyway, give it some thought. We never stored optical photons in Qweak simulations, only photo-electrons with an efficiency.

[cameronc137]

Correct, storing just the photo-electrons that have been converted with some efficiency should be our goal. Is that what is done now with the efficiency and post-step hit storage that you incorporated in the fix to issue #127? Or does relying on efficiency require changing the definition of "opticalphoton" detectors?

The complaint about factors of 12-14 came from misunderstanding hit storage. I thought hits only registered on entry to a volume, when in fact hits are registered at each step within a detector volume, so this is now clarified and doesn't constitute an issue.

With the bugfix our photo-electron counts are generally behaving, and if we find any more problems we will create a new issue with clearer steps for repeating.

[wdconinc]

I don't think you even need "opticalphoton" for the cathode... but I may be wrong. In any case, since there's no RINDEX is defined for that, optical photons won't propagate. You don't need "opticalphoton" for the interior of the light guide etc.