LArG4: diffusion causes errors in SpaceCharge computation
Working on issue #15100 with the first set up described there by Wesley Ketchum, I noticed a load of error messages in the log like:
%MSG-w LArVoxelReadout: LArG4:largeant 12-Jan-2017 18:50:29 CST run: 1 subRun: 1 event: 1 unable to drift electrons from point (0.0507348,-68.8742,970.816) with exception ---- Geometry BEGIN Can't Find Nearest Wire for position (-0.6,-nan,-nan) in plane C:0 T:0 P:2 approx wire number # -2147483648 (capped from 0) ---- Geometry END %MSG
LArVoxelReadout::DriftIonizationElectrons()processes a energy deposit from Geant4 which is close to the border of the TPC
- diffusion moves part of the charge outside the TPC (or outside the domain of space charge information)
- space charge service reports that the shifted position for a point outside its domain is
NearestChannel()is asked which is the closest wire to that position, and it throws an exception
LArVoxelReadout::DriftIonizationElectrons()catches it, prints the reported message and forgets
the restthat part of the energy deposit
The solution needs to be discussed with the users and the author (Michael Mooney).
#4 Updated by Gianluca Petrillo about 4 years ago
- Description updated (diff)
I should have stated more clearly that my "explanation" is just a
hypothesis guess, that I have not verified at all.
It may be that
nan come from math domain errors in the evaluation of the parametrisation, or from lookup to uninitialised memory, or who knows where.
(edited the description to reflect that)
#6 Updated by Gianluca Petrillo about 4 years ago
- % Done changed from 0 to 60
I have stumbled into this again while holding a debugger in my hand, so I fired it.
It turns out this problem can be indeed be triggered by the transverse diffusion, but in an unexpected way.
The displacement of charge close to the first wire plane will move the deposit beyond the plane. The drift distance and time become negative and all the bets are off. In particular, the RMS of the transverse diffusion is parametrised with the square root of the drift time, that now is a fat
NearestChannel() correctly rejects.
My suggestion is to cap the longitudinal displacement of the deposit. In the region close to the front wire plane, I think this is acceptable.
#7 Updated by Gianluca Petrillo about 4 years ago
- Assignee set to Gianluca Petrillo
- % Done changed from 60 to 100
I received the approval of Michael Mooney on the proposed change.
The change is in
develop now (larsim:7817d37596b23e45e1d4a86249a85dcdc8675a99).
Considering how it went, I am posthumously assigning this ticket to myself.
#9 Updated by Gianluca Petrillo almost 4 years ago
An analysis has shown that when the fix is introduced the random stream for diffusion is affected.
This is now understood: when the fix activates, the charge is placed on the wire plane, at drift distance 0, and therefore no diffusion happens. In that case, the code does not extract the random numbers for the displacement from diffusion. Before the fix, those numbers would be extracted (and an attempt to use them to evaluate a displacement with RMS
nan would be done, which would evolve into the error message we observed).
NuRandomService to use
perEvent random policy, only the events with this issue are affected. Otherwise, all the events following the first manifestation of the problem are going to differ respect to unpatched runs.
I expect that close to every event with cosmic rays will have one ray cross the anode plane, and as a consequence trigger the issue. Single particle and neutrino-only runs might be, on the other end, almost completely unaffected.