Bug #23457

LArReco Calorimetry module places absolute cut on z position which is not detector independent

Added by Tracy Usher 8 months ago. Updated 7 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Occurs In:


Christian Farnese is studying calorimetry with the ICARUS detector and reports the following problem:

... I am slowly proceeding on the studies I presented during the last Monday meeting related to dEdx evaluation...

in particular I am now trying to prepare a code that use the dE/dx measurement for the calibration of the detector: so I use a large number of cosmic muon tracks to evaluate channel by channel the dE/dx... but I discover something strange: the dE/dx was calculated only for the collection channel exceeding something like 2000... debugging in icaruscode I understand that there cut was not on the channel number but in the z coordinate... debugging outside icaruscode (installing in particular larreco) I discover that if you look to line 373 of the Calorimetry module in larreco

there is a cut on z at -100, that is clearly a problem for us (our z coordinate arrive to ~ -900)... it seems that removing that line, the problem I found is solved! You can find also just the result on 10 cosmic events: in blu the z coordinate of the 3D points with a dE/dx evaluated before removing the line I mentioned while in red you can see the additional points obtatined removing the line...

Indeed, if one looks at line 373 of the module one see:

if (xyz3d[2]<-100) continue

The commit messaging implies this line appeared as something related to MIcroBooNE where z=0 is at the edge of the TPC, not the center. For ICARUS z=0 is in the center, this line essentially eliminates nearly half the active volume.

I'm assigning to Gianluca since I believe he has already a solution...

Associated revisions

Revision 30baf419 (diff)
Added by Gianluca Petrillo 8 months ago

Make the cut on trajectory point position configurable.

In addition, make more extreme the value of some extreme constants that were not that extreme after all.
This solves LArSoft issue #23457.

Revision d189c4ca (diff)
Added by Gianluca Petrillo 8 months ago

Making the cut on trajectory point position optional.

This solves issue #23457.


#1 Updated by Tingjun Yang 8 months ago

I think I added that line when we first wrote the module for ArgoNeuT to ignore badly reconstructed points. Since most of the LArTPCs starts from z = 0, we have not had a problem with it yet.

I think the track reconstruction is mature enough that we don't need that check any more. If it causes problems for ICARUS, it should be removed.

#2 Updated by Tracy Usher 8 months ago


#3 Updated by Gianluca Petrillo 8 months ago

  • % Done changed from 0 to 90
  • Status changed from New to Work in progress
  • Co-Assignees Gianluca Petrillo added

A fix is pushed in larreco branch feature/gp_Issue23457 for testing.
The relevant commit is larreco:30baf419.

A new configuration parameter is introduced for Calorimetry module: NotOnTrackZcut (default to -100.0 for backward compatibility) excludes all points with z smaller that the parameter value.

Another change is the change of some "magic" invalid values from -1000 to std::numeric_limit<double>::lowest(): 1000 cm (10 m) is not so out of the world for ICARUS.

#4 Updated by Gianluca Petrillo 8 months ago

  • Description updated (diff)

#5 Updated by Gianluca Petrillo 8 months ago

After Tingjun comment, we should consider to turn the default value to not to apply that cut at all.
But I would like an all clear from the experiments before doing that.

#6 Updated by Gianluca Petrillo 8 months ago

After having received approval by e-mail by Tingjun and Tracy, I am pushing a change to make this cut optional.
If can be restored in its past glory adding to the configuration of the module:

NotOnTrackZcut: -100.0

New commit is larreco:d189c4ca, still in larreco branch feature/gp_Issue23457.

This definitely makes it a breaking change.

#7 Updated by Gianluca Petrillo 8 months ago

  • % Done changed from 90 to 100
  • Status changed from Work in progress to Resolved

#8 Updated by Lynn Garren 7 months ago

  • Status changed from Resolved to Closed

This is in larsoft v08_33_00

Also available in: Atom PDF