Bug #24430

Wrong position of reflective foil on OpFastScintillation in larsim

Added by Iker de Icaza Astiz 11 months ago. Updated 11 months ago.

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


Estimated time:
Occurs In:


I came across this issue whilst refactoring the code on larsim/LegacyLArG4/OpFastScintillation.cxx

The variable fplane_depth is effectively used as the X coordinate of the foils in SBND. Given SBND's geometry this should be close to 0. However printing it out comes to 2.6. Hence, mistakingly, the position of the foils are 2.6 cm for TPC0 and -2.6 cm for TPC1.

I came across this issue because I made the assumption that the region inclosed in between the reflecting foils should yield no detectable hits at all, VUV or VIS. This might still be a sensible assumption for geometries where there's a volume of LAr inclosed between reflecting foils. Whilst keeping such condition wouldn't affect SBND, the fact is the volume should be ~0.2 cm wide.

This variable is assigned with:

fcathode_centre = geo->TPC(0, 0).GetCathodeCenter();
fplane_depth = std::abs(fcathode_centre[0]);

My guess is that this issue points to a combination of problems with:
  • SBND geometry
  • geo->TPC(0, 0).GetCathodeCenter() pointing to the wrong object

The outcome is that the amount of VISHits and their arrival times is slightly biased. Reckon about ~1 % for the later.

I would also like to bring to attention that in larsim/PhotonPropagation/, where OpFastScintillation code was copied to, the variable fplane_depth is not initialised.

I raise this issue here because it might be relevant to other experiments.


#1 Updated by Kyle Knoepfel 11 months ago

  • Status changed from New to Under Discussion

This will take some discussion among the LArSoft experiments. We will send an email to appropriate individuals to look at this issue.

#2 Updated by Gianluca Petrillo 11 months ago

Clarification: GetCathodeCenter() does not point to any object.
LArSoft has no protocol too describe the cathode, and the geometry calls "cathode" the far side of the TPC.
It works well enough most of the times, but it's not it.
An extension of the protocol can address this problem.

Even easier it would be if we adopted the more flexible initialisation scheme implemented to accommodate pixel geometries. Just saying.

#3 Updated by Alexander Himmel 11 months ago

I can loop in Muve, who did a bunch of the refactoring, to address the uninitialized variable, but maybe it's easier to take care of it as part of the more general fix?

#4 Updated by Kyle Knoepfel 11 months ago

We will schedule a meeting to discuss this issue and the other OpFastScintillation issue regarding double <-> int narrowing conversions.

Also available in: Atom PDF