Running applications in 10.04 with the Shielding physics list, I get some weird tracking behaviour. Specifically, in an empty (G4_Galactic) world volume, if I launch gamma rays, each event has a GeomNav1002 warning message: -------- WWWW ------- G4Exception-START -------- WWWW ------- *** G4Exception : GeomNav1002 issued by : G4PathFinder::ReportMove() Endpoint moved between value returned by ComputeStep() and call to Locate(). Change of (End) Position / G4PathFinder::Locate is 0.1589225889114108 mm long and its vector is (-0.1193944232074333,0.1038561127083568,0.01467204233836128) mm Endpoint of ComputeStep() was (15.76542646683762,116.4448749788099,331.932937400214) and current position to locate is (15.64603204363019,116.5487310915183,331.9476094425523) *** This is just a warning message. *** -------- WWWW -------- G4Exception-END --------- WWWW ------- I don't see this in 10.2 or 10.3. I also don't see this with the same setup, but using the FTFP_BERT physics list.
Mike, can you please attach a test case which reproduces the problem? Assigning issue to physics-list for inspection.
Mike, what kind of transportation is used?
Vladimir, the job uses G4CoupledTransportation, according to the log file. Gabriele, Dennis and I will try to construct a simpler test case than the full CDMS simulation :-/
Seeing that Coupled Transportation is triggered (or scoring) - could you provide some information about whether there is a parallel world ? Or why else it is triggered. Anything different about the handling of multiple scattering (e.g. a variant EM physics builder ? Is there anything else that could be said to be unusual about the simulation ?
Hi, John et al. I have sent John tracebacks and object state dumps from our application, which helped isolate the issue to CoupledTransportation. I noticed that on the first trigger of the problem, it happened on the first step of a new track (track #543 of some event, so not every time), rather than after some transport distance. We are using the parallel world to do custom "volume scoring" (defining volumes that match the envelope of some of our detailed detector assemblies, with the ability to record substantial track details on entry and exit). Whether such scoring is done or not is a macro configurable option, so on some jobs there may not be anything built in the parallel world. We think it is important to have exactly the same physics configuration for production, whether or not such "scoring" is used or not, so disabling the parallel world would be a hack, not a suitable long-term solution.
In case it helps to debug: these symptoms are also observed in example electronScattering2 in release 10.4. They were not observed in 10-03-ref-10. ScoringManager is instantiated. It turns out for electronScattering2 that ScoringManager was not used--not instantiating it fixed the problem. (Of course this fix doesn't work when one wants to use ScoringManager.)
It's good to know that this problem happens with official G4 examples as well, and seems to be isolated to having parallel worlds active (i.e., G4CoupledTransportation instead of G4Transportation). Is it possible that there's a relationship between this issue and #1953 (https://bugzilla-geant4.kek.jp/show_bug.cgi?id=1953), where the parallel world has a stale step pointer?
The fix is now implemented in tag geomnav-V10-04-01. It will be included in next patch release.
