Possible Issues with Green Crystal BGO Suppression

[cnatzke]

ErrorReport.sh

HOSTNAME     = torvaldon.triumf.ca
SYSTEM       = Linux
OS           = Ubuntu
VER          = 20.04
GRSISYS      = /home/S9038/GRSISort/v4.0.0.2
ROOTSYS      = /home/S9038/cern/root/root-current
ROOT Version = 6.22/08

Computer and Path to File that failed:

GRSISort Branch = master

commit 9b6e40d1f3335049805a2766c2913e93c95833a5 (HEAD -> master, origin/master, origin/HEAD)
Merge: 9dbf0a3f 911396ce
Author: Vinzenz Bildstein <vbildste@uoguelph.ca>
Date:   Wed Jun 23 20:58:51 2021 -0400

    Merge pull request #1185 from VinzenzBildstein/master

    Added bin directories of data parser libraries to PATH

Bug Description There is an inconsistency with the Compton suppression algorithm in the green crystals. I generated a GRIFFIN HPGe-Bgo hit pattern from a 60Co source and @AdamGarnsworthy noticed the green crystals are show more hits than the other crystals in the clover. Furthermore this is not consistent across all clovers.

for (auto g1 = 0; g1 < fGrif->GetSuppressedMultiplicity(fGriffinBgo); g1++) {
    TGriffinHit * grif_hit1 = static_cast<TGriffinHit*>(fGrif->GetSuppressedHit(g1));

    for (auto b1 = 0; b1 < fGriffinBgo->GetMultiplicity(); b1++) {
        TGriffinBgoHit* bgo_hit1 = static_cast<TGriffinBgoHit*>(fGriffinBgo->GetHit(b1));
         hist_2D["grif_bgo_hitpattern_sup"]->Fill(grif_hit1->GetArrayNumber(), bgo_hit1->GetArrayNumber());
     } 
} 

Zooming into a clover we see the second column, representing the green crystal, is brighter than the other three. In addition the bright spot corresponds to the green BGO suppressor channels along the y-axis.

If I look at other set of clovers I don't see these bright spots.

Has anyone else seen this behaviour in their data-set? Or is this unique to my data?

[cnatzke]

For completeness here is the same matrix created using unsuppressed GRIFFIN hits:

[VinzenzBildstein]

What does the hit pattern of the BGOs in general look like? Meaning not with a Griffin hit in coincidence but from a single loop over all BGO hits? This could just be a case of the green BGOs counting more (due to the direction of the radiation or because the thresholds are lower or the channel is noisier).

What you're plotting is essentially saying give me all BGO hits that are not within 300 ns of a GRIFFIN hit (or whatever you are using as a time condition for suppression), but are within 2000 ns of a GRIFFIN hit (or whatever your build window length is). So essentially only time-random hits. And if some detectors count more the amount of time-randoms will be more.

[VinzenzBildstein]

Have you had a chance to check this @cnatzke? Like I said, I don't think that this is a GRSISort issue, but something in the data (noise or a real effect in count rate).

[cnatzke]

Thanks for the reminder. I still need to generate the same histogram from a different experiment to compare the results. I will do so this week and post the result here.

[cnatzke]

I created the same matrix using a post beam 60Co calibration run (run15628) and do not see a bias towards the green crystal.

As you suggested this may be an issue in the data rather than the sort code.

[cnatzke]

Since this is not an issue with GRSISort I'm closing the issue.