Optical photons no longer reflect as expected

[cameronc137]

Environment: (where does this bug occur, have you tried other environments)

• branch (master for latest released): develop here and develop in https://github.com/sbujlab/remoll/ fork
• revision (HEAD for most recent): HEAD
• OS or system: CENTOS 6.9
• Special ROOT or Geant4 versions? 5.34 and geant4.10.04.p02

Steps to reproduce: (give a step by step account of how to trigger the bug)

1. clone a clean copy of the remoll (either version JeffersonLab or sbujlab), go to develop branch, cmake and make

2. execute ./build/remoll macros/blackening_external.mac

3. open the output file in root and check the number of optical photons hitting the PMT cathode with T->Draw("hit.det","hit.det==50701 && hit.pid==0") and the number of electrons hitting the quartz tile with T->Draw("hit.z","hit.pid==11 & hit.det==50001")

4. Alternatively execute ./build/remoll and within remoll run /control/execute macros/vis.mac

5. Shoot several particles at the quartz and see that in fact no photons internally reflect
   (In the sbujlab version of the repo the beam generator movement macro commands are different, so this may take some finessing, or just shift the detector_5open.gdml sub-file to the +x direction by 975 mm and shoot the standard beam generator at it)

Expected Result: (what do you expect when you execute the steps above)

When I do the same thing in the sbujlab version of the repository (a stale old branch that has been manually fastforwarded some) I see ~ 24 PEs on the photocathode per electron hitting in the quartz.

Actual Result: (what do you get when you execute the steps above)

The photons do not internally reflect in the quartz.
I see 0.1 PEs per electron on quartz, and those are probably coming from other sources.

[cameronc137]

The issue lives somewhere in here: sbujlab@b4d61da (plus the following commit fixes 2 errors I introduced in merge)

[cameronc137]

The bug lives specifically in between commits b8fec16 and 8bc00f7

The 14 commits in between those two do not successfully compile for me, so I cannot say which commit introduces the exact issue.

I have made two new branches, one that still works, and the other that does not, and I include in those branches everything required for exemplifying this problem (in visualizer).

To replicate this intended behavior/the bug in https://github.com/JeffersonLab/remoll/tree/bugfix-opticalReflections or https://github.com/JeffersonLab/remoll/tree/bugfix-opticalReflections-broken respectively please compile remoll as normal; ./build/remoll; and then from within the gui control/execute vis.mac which will run a single electron straight through the quartz tile. In the working case you will see the photons reflect inside the quartz and light guide, and in the broken one they simply shoot downstream (and problematically bounce around on the logical volume walls, which appears to change too as you go farther along the commit history up to the current HEAD... but this may just have to do with the target volume needing to be included at the set of commits in question).

[cameronc137]

This is the entire cause of the bug:

remoll/remoll.cc

Line 124 in 2440574

physlist->RegisterPhysics(new G4ParallelWorldPhysics(parallel_name));

Including the parallel world physics list kills optical photons ability to interact properly (and may affect other physics processes as well, possibly related to Rakitha's issue?)

Commenting out that one line fixes the optical physics problem. Would it be possible to move the parallel world physics registering line to the remollPhysicsList.cc program (and give it some turn on/off macro commands, like the other physics lists?)

[cameronc137]

I moved the parallel world physics list to remollPhysicsList.cc, but I don't know how to check that I didn't break it in the process.

[cameronc137]

@wdconinc - Unfortunately my approach to fixing this issue by making parallel world physics optional does not fix the problem that optical physics breaks when parallel physics is enabled. This means that the pion_optical_response.mac macro is broken and cannot work (though it was already broken before I tried fixing things anyway).

What should we do? Allow parallel physics to break optical, or see if there is some more detailed solution and try to make them work simultaneously?

Also, Rakitha found his bug with the neutrons, and it was due to some other gdml issue (though I still don't quite understand why only he was seeing the problem).

[wdconinc]

That test case geometry in vis.mac and 5open has some 17m overlaps...

[wdconinc]

With develop 027b69d.

Geometry: red is overlapping volumes (to varying degress).

Vis.mac output:

It seems that there is 1) volume overlap in the test case, 2) reflection of at least some photons.

If the issue of no optical photon reflection is still there, I think it would be help to:

• have a clean test case: a quartz cube of 1 x 1 x 1 at 0, 0, 0 without any overlap

[wdconinc]

This makes it clearer (top view):

[wdconinc]

Moving beam to shoot at quartz, hash 2552c97

[wdconinc]

So, @cameronc137, at least the default behavior in develop seems to work. Now I can try to get parallel worlds to work again too, right? I'll keep doing that this issue.

[cameronc137]

Yes, this looks to be working fine with just the optical physics list set, and I've run a few simulations recently using this that give physically reasonable results.

[wdconinc]

Ok, I can confirmed now that this does not work with parallel world enabled (/remoll/physlist/parallel/enable either before or after enabling optical). Good, now we can try to fix this :-D

[wdconinc]

Weirdnesses (diffs below where left is parallel disabled, right is parallel enabled):

• enabling parallel world causes overlaps to be flagged in the real world

                                                              >
                                                              > -------- WWWW ------- G4Exception-START -------- WWWW -------
                                                              > *** G4Exception : GeomVol1002
                                                              >       issued by : G4PVPlacement::CheckOverlaps()
                                                              > Overlap with volume already placed !
                                                              >           Overlap is detected for volume lg_50001
                                                              >           apparently fully encapsulating volume pmtCathode_50
                                                              >           at the same level !
                                                              > *** This is just a warning message. ***
                                                              > -------- WWWW -------- G4Exception-END --------- WWWW -------
                                                              >

• enabling parallel world makes volumes heavier:

logicMother_PV[1] logicMother 1 Vacuum 4.97922 kg             | logicMother_PV[1] logicMother 1 Vacuum 4.97833 kg
  logicMotherVol_5open_PV[2] logicMotherVol_5open 1 Air 4.979 |   logicMotherVol_5open_PV[2] logicMotherVol_5open 1 Air 4.978
    detector_50001[3] quartzVol_50001 9 Air 4.69532 kg        |     detector_50001[3] quartzVol_50001 9 Air 4.69443 kg
      quartzRec_50001[4] quartzRecVol_50001 0 Quartz 188.268  |       quartzRec_50001[4] quartzRecVol_50001 0 Quartz 188.31 g
      ref_50001[5] refVol_50001 0 Air 391.564 mg /remoll/det_ |       ref_50001[5] refVol_50001 0 Air 391.497 mg /remoll/det_
      refSkin_50001[6] refVolSkin_50001 0 Aluminium 171.272 g |       refSkin_50001[6] refVolSkin_50001 0 Aluminium 169.907 g
      reflector_50001[7] reflectorVol_50001 0 Aluminium 10.29         reflector_50001[7] reflectorVol_50001 0 Aluminium 10.29
      lg_50001[8] lgVol_50001 0 Air 2.41827 g  /remoll/det_50 |       lg_50001[8] lgVol_50001 0 Air 2.41717 g  /remoll/det_50
      lgSkin_50001[9] lgVolSkin_50001 0 Aluminium 707.323 g   |       lgSkin_50001[9] lgVolSkin_50001 0 Aluminium 708.706 g  
      pmt_50001[10] pmtVol_50001 0 Aluminium 1.85528 kg /remo |       pmt_50001[10] pmtVol_50001 0 Aluminium 1.85658 kg /remo
      pmtCathode_50001[11] pmtCathodeVol_50001 0 Photocathode         pmtCathode_50001[11] pmtCathodeVol_50001 0 Photocathode
      pmtSkin_50001[12] pmtSkinVol_50001 0 Aluminium 1.72534  |       pmtSkin_50001[12] pmtSkinVol_50001 0 Aluminium 1.72307 

[wdconinc]

Relevant upstream report: https://bugzilla-geant4.kek.jp/show_bug.cgi?id=1953

[wdconinc]

The upstream bug report is dismissed as not reproducible, but it describes exactly where the problem occurs in our code (G4OpBoundaryProcess.cc:L183 in geant4.10.04.p02). Makoto writes "Most-likely, this was caused by the user's code that has a mismatch between having the parallel world geometry but no associated G4ParallelWorldProcess process (or vice versa)" but that doesn't make it clearer to me :-/

[wdconinc]

Reproduced in a standard geant4.10.05 example and reported upstream as https://bugzilla-geant4.kek.jp/show_bug.cgi?id=2113. Workaround for now: no parallel worlds for geant4 versions <= 4.10.05 if you want optical photons to be simulated correctly :-(

[wdconinc]

Confirmed fixed in upstream development. Should be fixed in release 4.10.05.p02 whenever it appears.

[wdconinc]

Fix released in upstream release 4.10.06.