search

GRIFFINCollaboration / detectorSimulations_v10

Geant4 version 10 of the simulation code for the GRIFFIN array and it's suite of ancillary detection systems.
MIT License
9 stars 14 forks source link

10.04 Track stuck warning #68

Open cnatzke opened 4 years ago

cnatzke commented 4 years ago

I am using the 10.04 branch and upon the simulation I get the warning 

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomNav1002
      issued by : G4Navigator::ComputeStep()
Track stuck or not moving.
          Track stuck, not moving for 10 steps
          in volume -av_15_impr_1_germaniumDlsBlock1_0_1_log_pv_0- at point (51.40323832896522,131.3838178554773,126.2179514017618) (local point (18.05933798738393,-25.7619894227668,8.010199300064244))
          direction: (0.6954296418896786,-0.5789532367957795,0.4256650828819338) (local direction: (0.4910281903581032,-0.8640490242794154,-0.1109531428821951)).
          Potential geometry or navigation problem !
          Trying pushing it of 1.000000038272682e-07 mm ...Potential overlap in geometry!

*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

multiple times per runtime. Has anyone else seen this?

The volume/coordinates change each time and this only occurs when there is more than detector in the simulation.

jsmallcombe commented 4 years ago

I have seen this before as it says its usually "Potential overlap in geometry" What setup are you using exactly? Have you written any new volumes yourself? It's usually good to shave 0.01-0.1mm off the thickness of touching volumes so that they aren't touching exactly.

cnatzke commented 4 years ago

What setup are you using exactly?

No suppressors in high-efficiency mode. I originally suspected it was the suppressors but that was not the problem.

Have you written any new volumes yourself?

Nope, vanilla geometry right after a git clone

jsmallcombe commented 4 years ago

Are you getting enough of them that it is significantly slowing down the simulation? It is possible this has always been a problem due to some tight fitting geometry (such as germanium deadlayer perhaps) but as it doesn't actually effect the results it's been ignored.

If you collect the list of volumes from the warnings e.g. "av_15_impr_1_germaniumDlsBlock1_0_1_log_pv_0" then it should be easy enough to work out which interface is causing the issue and trim it a smidge.

cnatzke commented 4 years ago

Turns out the issue was in the macro. When placing a detector the command should be: 

 /DetSys/det/SetCustomPosition n n 0                                                                
 /DetSys/det/addGriffinCustomDetector n

rather than: 

/DetSys/det/addGriffinCustomDetector n
/DetSys/det/SetCustomDeadLayer n n 0

where n is the detector position.

The SetCustomPosition call also sets the dead layer for the given detector position making the SetCustomDeadLayer unnecessary. In fact calling SetCustomDeadLayer for any position above 4 causes an error based on how the simulation parses the run macro.