Created attachment 546 [details] The full description of the bug report Hello, my name is Sangsik Yoon, and I am a Belle II student member. When generating particle gun 1GeV muons in Belle II software framework, we noticed errors as below: [ERROR] In G4MagInt_Driver::AccurateAdvance(), GeomField1001: Proposed step is zero; hstep = 0 ! { module: FullSim } [ERROR] In G4MagInt_Driver::AccurateAdvance(), GeomField1001: Proposed step is zero; hstep = 0 ! { module: Ext } [ERROR] In G4MagInt_Driver::AccurateAdvance(), GeomField1001: Proposed step is zero; hstep = 0 ! { module: Muid } I have attached the full description of the bug report. Thank you very much, and please feel free to contact us anytime. Best, Sangsik Yoon
Dear Sandsik Yoon, Thank you for your report. I have looked at the slides in which you describe the problem. I find it difficult though to use the long output of the debugger in its current form. Could you please upload each text output file as a simple text file(s). That will allow us to use any text editor to view this file instead of using a PDF viewer. Best regards, John Apostolakis
Created attachment 549 [details] This input file for gdb creates "watch.txt" file.
Created attachment 550 [details] This file shows the changes of values of two variables: CurrentA_PointVelocity and CurrentB_PointVelocity. The value of CurrentA_PointVelocity at $87=87 and the value of CurrentB_PointVelocity at $98=98 are the same, which leads to the hstep = 0 error.
Created attachment 551 [details] This input file for gdb creates "detector.txt" file.
Created attachment 552 [details] This file shows the information of detectors when the errors occurred. I do not think this file may be useful, but I have attached it to describe that hstep = 0 errors occurred at a variety of detectors.
(In reply to John Apostolakis from comment #1) > Dear Sandsik Yoon, > > Thank you for your report. > > I have looked at the slides in which you describe the problem. > > I find it difficult though to use the long output of the debugger in its > current form. Could you please upload each text output file as a simple text > file(s). > > That will allow us to use any text editor to view this file instead of using > a PDF viewer. > > Best regards, > John Apostolakis Dear John Apostolakis, I have added new attachments : "input_watch.in", "watch.txt", "input_detector.in", and "detector.txt" I hope "input_watch.in" and "watch.txt" files may be helpful. I think that it requires to run Belle II Software to test a patch file, so please let me know at any time if you need any further information. Best regards, Sangsik Yoon
Hi Sangsik, Sorry for the long silence. I have tried in the last days to understand the output of the debugger which you have posted. To do this I processed the output of the printing of the watchpoints from the debugger in order to see the evolution of CurrentA_PointVelocity and CurrentB_PointVelocity - in particular their values of the distance along the track, the position and the momentum 3-vectors. I attach the file which I created, to document this progress more easily by putting the values of CurrentA_PointVelocity and CurrentB_PointVelocity into columns using a script. I do not suggest that this identifies the problem yet, but I want to keep this to help in further investigation.
Created attachment 582 [details] Progression of the state of CurrentA_PointVelocity and CurrentB_PointVelocity This file with very long lines contains the current values and the changes in CurrentA_PointVelocity and CurrentB_PointVelocity, extracted from watch.txt
Created attachment 583 [details] Script used to create comparison of values of CurrentA,B_PointVelocity
Dear Dr. John Apostolakis, Thank you for letting me know about the progress of this issue. As far as I remember, the line 449 in G4MultiLevelLocator.cc makes CurrentA_PointVelocity and CurrentB_PointVelocity have the same value. Please let me know if there is any further progresses or if there is anything that I need to test in the Belle II Software environment. Best Regards, Sangsik Yoon
Used new code to store the intermediate points / intervals of integration within AccurateAdvance, and adding a print statement inside the error report. Dennis Wright reran the application, and provided the new output from the errors. I copy below the first case. ********* Zero step event #1 **************** ERROR> Point B has gone past point A ** Change records: MLL: iters = 4 ===================================================================== Size of individual change record: startA : 2 endB : 5 ===================================================================== Change# Iter CodeLocation Length-A (start) Length-B (end) ===================================================================== 1 0 2 Initialising 0 30.11455759098148 0 2 2 0 3 IntersectsAF 24.46186452078947 3 1 3 IntersectsAF 24.45830312608917 4 2 3 IntersectsAF 24.45830136494451 5 3 4 IntersectsFB 24.45830136436696 6 3 6 RecalculatedB 24.45830136436696 [ERROR] In G4MagInt_Driver::AccurateAdvance(), GeomField1001: Proposed step is zero; hstep = 0 ! { module: Ext }
Dear Sangsik, Is this still an issue in Belle II ? Best, John
DearJohn, Sangsik moved to another experiment. I will ask around Belle II if they are still seeing the error.
We've added additional logging functionality to aid in diagnosing such problems. Please let us know if it persists.
