Bug #24301

Erroneous calculation of Rectangle_SolidAngle() in OpFastScintillation.

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

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


Estimated time:
Occurs In:


The function Rectangle_SolidAngle() returns the solid angle seen from a given position to a rectangular optical detector, sort of a geometrical acceptance calculation to weight how many photons from a particular interaction in space will be seen by a detector.

Inside the function there are checks to decide the relative position and do the calculation accordingly. The first block of those is:

 if( (std::abs(v.Y()) > out.w/2.0) && (std::abs(v.Z()) > out.h/2.0)){
      double A, B, a, b, d;
      A = std::abs(v.Y())-out.w/2.0;
      B = std::abs(v.Z())-out.h/2.0;
      a = out.w;
      b = out.h;
      d = std::abs(v.X());
      double to_return = (Rectangle_SolidAngle(2*(A+a),2*(B+b),d)-Rectangle_SolidAngle(2*A,2*(B+b),d)-Rectangle_SolidAngle(2*(A+a),2*B,d)+Rectangle_SolidAngle(2*A,2*B,d))/4.0;
      return to_return;

Note that here it's comparing width against Y and height against Z. Were it should be the other way around! This is where I first noticed there was something odd.

To be certain I have printed the values of the dimensions of the rectangle in SBND, I get:

out.w = 7.5
out.h = 9.8

these are correct and reflect the actual orientation of the ARAPUCA crystals in SBND.

To reiterate: width of the rectangle out.w should be compared against Z, and height out.h against Y.

This function is also used to calculate the solid angle from the reflecting foils. In there I get:

out.w:  400
out.h:  500

These are swapped! the effect is that solid angle calculation from the interaction point to the reflecting foils is correct. It still is incorrect for the detectors that only see reflected light.

Digging deeper I see that there are other places in which the values have been swapped. I count three swaps.

I have notified Diego Gamez and Patrick Green the creators of this module.

Note that this also affects PDFastSimPAR_module inside PhotonPropagation.

For SBND where the ARAPUCA crystals are closer to being squares this is not a huge problem, for DUNE it's a different story.


#1 Updated by Iker de Icaza Astiz 11 months ago

I have created PR #13 to fix this:

#2 Updated by Kyle Knoepfel 11 months ago

  • Status changed from New to Assigned

#3 Updated by Lynn Garren 11 months ago

  • Status changed from Assigned to Resolved

larsim PR 13 is merged with develop and will be in the next larsoft release.

#4 Updated by Lynn Garren 11 months ago

  • % Done changed from 0 to 100

#5 Updated by Lynn Garren 11 months ago

  • Status changed from Resolved to Closed

The fix is in larsoft v08_50_00.

Also available in: Atom PDF