Project

General

Profile

Bug #15131

LArG4: diffusion causes errors in SpaceCharge computation

Added by Gianluca Petrillo almost 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
Simulation
Target version:
-
Start date:
01/12/2017
Due date:
% Done:

100%

Estimated time:
Spent time:
Occurs In:
Experiment:
-
Co-Assignees:
Duration:

Description

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

They are likely My guess, not backed by any analysis of the problem, is that it's caused by the following sequence:

  1. LArVoxelReadout::DriftIonizationElectrons() processes a energy deposit from Geant4 which is close to the border of the TPC
  2. diffusion moves part of the charge outside the TPC (or outside the domain of space charge information)
  3. space charge service reports that the shifted position for a point outside its domain is nan
  4. NearestChannel() is asked which is the closest wire to that position, and it throws an exception
  5. LArVoxelReadout::DriftIonizationElectrons() catches it, prints the reported message and forgets the rest that part of the energy deposit

The solution needs to be discussed with the users and the author (Michael Mooney).


Related issues

Related to LArSoft - Support #15100: Need faster NearestWire look up methodClosed01/11/2017

Associated revisions

Revision 7817d375 (diff)
Added by Gianluca Petrillo almost 4 years ago

Prevent space charge distortion from making charge cross the wire planes.

This should solve issue #15131 .

Revision bff683e7 (diff)
Added by Gianluca Petrillo almost 4 years ago

Prevent space charge distortion from making charge cross the wire planes.

This should solve issue #15131 .

Revision a02ae49b (diff)
Added by Gianluca Petrillo over 3 years ago

Prevent space charge distortion from making charge cross the wire planes.

This should solve issue #15131 .

Revision bcd85e21 (diff)
Added by Gianluca Petrillo over 3 years ago

Prevent space charge distortion from making charge cross the wire planes.

This should solve issue #15131 .

History

#1 Updated by Gianluca Petrillo almost 4 years ago

  • Related to Support #15100: Need faster NearestWire look up method added

#2 Updated by Gianluca Petrillo almost 4 years ago

  • Occurs In v06_19_00 added
  • Occurs In deleted (v06_17_00)

#3 Updated by Gianluca Petrillo almost 4 years ago

  • Description updated (diff)

Prompted by a question by Wesley, I checked that actually only the electron "packets" that are shifted out of the volume are lost.
I corrected the main description of the issue accordingly.

#4 Updated by Gianluca Petrillo almost 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)

#5 Updated by Lynn Garren almost 4 years ago

  • Status changed from New to Feedback

Bill and Libo, would it be possible for the simulation group to investigate this problem?

#6 Updated by Gianluca Petrillo almost 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 nan, which 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 almost 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 larsim develop now (larsim:7817d37596b23e45e1d4a86249a85dcdc8675a99).

Considering how it went, I am posthumously assigning this ticket to myself.

#8 Updated by Gianluca Petrillo almost 4 years ago

  • Status changed from Feedback to Resolved

#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).

When setting 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.

#10 Updated by Katherine Lato over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF