## Bug #24301

### Erroneous calculation of Rectangle_SolidAngle() in OpFastScintillation.

100%

**Description**

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.

### History

#### #1 Updated by Iker de Icaza Astiz 11 months ago

I have created PR #13 to fix this:

https://github.com/LArSoft/larsim/pull/13

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