| Summary: | Occasionally occurring infinite loop in optical photon tracking | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | Matthias Nagl <geantbugs> |
| Component: | processes/optical | Assignee: | gum |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | John.Apostolakis |
| Priority: | P5 | ||
| Version: | 9.4 | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | https://code.google.com/p/scintillate/ | ||
|
Description
Matthias Nagl
2011-09-02 17:21:00 CEST
Accepting the report - and trying to change it to "Geant4" product. I was able to download your sources, compile, link and run. However, I see that each event is rather lengthy and you require 10000 events. Do you have the random number seed of the event that loops - assuming that you continue to see infinite loops with 9.5 as well. Most ideally, we'd know the origin, energy, polarization and direction of the optical photon that loops in your geometry and launch it alone. Would you be able to extract this information and are you able to launch individual photons in your simulation? Sorry for the long delay! There are several cases where the problem occurs almost every time I start the particular macro file - even using the most recent version of Geant4. Two examples which you can find in the google-code repository are: runs/LaBr_conical40x20x10_whiteground_1275keV_iso.mac runs/PerfectLYSO_20x40_whiteground_1275keV_0deg.mac Despite many attempts I was not able to get any of these to pass all 10000 runs without hanging. Is there an easy way to get the information you requested from a hanging instance? Hi Matthias, To know the random number seed at the beginning of the event that is looping (equivalent to knowing the seed at the end of the previous event) you need to code equivalent to what is coded in /examples/extended/field/field04/src/F04EventAction.cc: http://www-geant4.kek.jp/lxr/source/examples/extended/field/field04/src/F04EventAction.cc#L86 and the rest in that example that's related to saveEngineStatus (F04RunActionMessenger.cc) Once you know the seed, and it is written to file, you can launch only that one event by seeding the program from the file and then you can debug where exactly the looping happens and maybe why. If you have access to the source code you can dig into it either with gdb or your own coded G4cout statements until you find where the loop is. Thanks, Peter Hello Peter, I added an UserEventAction calling CLHEP::HepRandom::saveEngineStatus in its BeginOfEventAction method. However I am not able to reproduce the infinite loop by reloading the last written engine status before looping in the beginning or in the UserEventAction of a subsequent run. is there anything to pay attention to? Cheers, Matthias I cannot reproduce the bug. 10000 events run through without an infinite loop when I install, compile, link and run the code myself. I'll relegate this bug-report to 'works-for-me'. I suggest that if the user finds the time, he compiles, links and runs his code against 9.4.p03. Maybe it 'resolved itself' since. In any case, I cannot trace the problem without more help from the user. If the event cannot be isolated, and the infinite loop reliably reproduced then the cause must be a memory issue caused by a previous event. In that case, the cause may not be reproducable except on the very platform where it appears. There have not been any other users claiming similar problems in their applications. So, in all likelihood cause for the problem lies with the user's code. |