TIGRESS Default Suppression

[sgillespie90]

Is your feature request related to a problem? Please describe. Now that TIGRESS is in GRIF16s the default suppression condition doesn't work anymore as the CFD time gate and energy conditions are different.

Describe the solution you'd like Change the TIGRESS Default Suppression to be the same as GRIFFIN, if we can preserve the TIG10s suppression as well by checking from Digitizer type that would be good.

Describe alternatives you've considered

Additional context

[VinzenzBildstein]

Can you clarify this for me (without me having to look through the code), do you want the default values for the suppression changed or do you want the way the suppression is done changed? If I remember correctly the way the suppression is done is completely different between Tigress and Griffin, so if you don't just want the default conditions to be changed, it would probably make most sense to create a new class for Tigress when sorted with GRIF16s (or rename the current class for use with TIG10s and re-write the existing class for use with GRIF16s).

[sgillespie90]

I want the way the suppression done is changed to the GRIFFIN style. In addition to different cfd values, the TIGRESS version only does suppression for certain combinations of Ge and BGO crystal numbers. This shouldn't be done the peak:total you get is around 10% worse than considering all combinations.

I think what I would like to see is that the current TIGRESS detector class (for TIG10s) be copied into a new detector class and the use the existing TTigress class for the GRIF16s. I will then re-write the TTigress class as necessary as I test things with the new DAQ.

[jhenderson88]

How does the efficiency change with the GRIFFIN vs TIGRESS suppression schemes? We set up the default TIGRESS suppression to be intentionally slightly conservative to avoid losing counts from random backgrounds, based on a HPGe segment vs BGO segment hitmap (with the idea that the user can define a more stringent suppression scheme of their own later).

I also don't see what this has to do with digitizer type. If you're going to change it, it should be changed for both. There's certainly no-need to duplicate the class over it.

[sgillespie90]

The peak to total for the GRIFFIN vs TIGRESS suppression if 52% vs 41%

[jhenderson88]

Not the peak to total: how many good (photopeak) counts are lost in the GRIFFIN scheme vs the TIGRESS one?

My thinking is/was that it's better by default to have a worse P/T but all of your statistics (and you can optimize the P/T later by setting a different scheme) than an excellent P/T without a good feeling for your statistics.

I don't recall what multiplicity we were running when we set up the suppression scheme, but it might have been rather high, so it's possible we had a lot of randoms and therefore were losing more events.

[sgillespie90]

There are more good events lost on the GRIFFIN scheme, but it is basically statistically insignificant (comparable to the uncertainties). Admittedly this was a low rate test, I am still waiting on some firmware updates before I can repeat the tests at high rate.

[jhenderson88]

Statistically insignificant is <1%, <10% in this case? If it's <1% or thereabouts then I'd say it's fine. I assume this is with 60Co? If you find similar with (for example) a relatively chunky 152Eu source then I'd have no objection to switching to the GRIFFIN scheme.

I don't think there's any real point making a new class though. Just set the energy and time gates as being digitizer dependent. Also remember that the TIGRESS backcatchers are CsI(Tl) so the time/energy response might be different than the defaults GRIFFIN.

More generally: If people are running analyses where the suppression is important they really should be defining their own schemes based on observed hit-patterns. The default should only really be used for online analyses.

[sgillespie90]

Statistical insignificant as in < 1% and yeah this was done with a 60Co source. The GRIFFIN defaults have generally been fine so far, but again this may change at high rates.

I'm not particularly attached to the idea of a new detector class for the TIG10's and would be happy if it just checks for digitizer. I just wanted to get an idea on what other people thought would be the best way forward so we can keep things consistent. I suspect this will not be the last time I need to change something now that the detectors are in GRIF16s (for the Ge and the ancillaries).

[VinzenzBildstein]

@sgillespie90, any further thoughts on how you would prefer this to be implemented?

I think it would be easiest to implement a new class and change the way the fragments are built into detectors depending on their digitizer type. Using just one class would probably also work, but things would be a bit messier, e.g. it would still need to have a vector of BGO hits, even if those aren't used for GRIFFIN digitizers.

[sgillespie90]

No I haven't thought any further about this and I wonder if its worth the effort to change this.

There aren't many unpublished TIGRESS data sets taken with the old DAQ (I think there are only two - three) and it't unlikely the people analysing them will actually update to the new GRSISort version.

[VinzenzBildstein]

I'm not sure I understand. Do you want to just leave things the way they are?

Or do you mean that we should just change the Tigress class to behave the same way as the Griffin class in version 4 and have people with old data continue to use version 3?

[sgillespie90]

Sorry I meant change it to the GRIFFIN style and everyone with the old data just uses version 3

[VinzenzBildstein]

Okay, sounds good. But I think I will first change Griffin as described in #1121.