[DEE] Add hardware thresholds to determine if a MDEEStripHit was a NearestNeighbor or not

[fhagemann]

Currently, MSubModuleChargeTransport generates up to three MDEEStripHits for each the HV and LV side, namely for the strip in which the original simulated hit took place, and the two adjacent strips. This part of the DEE does not know if a MDEEStripHit will end up triggering, becoming a NN strip hit, or not being read out at all.

In MSubModuleStripReadout, we apply what I call a "hardware threshold", which is a strip-specific energy threshold in ADC units to determine if a strip triggered or not. The current logic is:

• If a MDEEStripHit exceeds its hardware threshold, then both neighbors should exist and be read out
• If a MDEEStripHit did not exceed its hardware threshold, it will only be read out (as a NN strip), if at least ONE of the adjacent strips exceeded its hardware threshold.

For this, I had to

• add a m_IsNearestNeighbor flag to MDEEStripHit
• write code to read a hardware threshold file (in MModuleEnergyCalibration), and code to apply it (in MSubModuleStripReadout)
• write a loop to iterate through all MDEEStripHits after the charge-transport simulations to:
  1. find all TriggeredStrips (above hardware threshold), all NeighborCandidateStrips (neighbors of strips above hardware threshold), all DeadStrips (without energy calibration)
  2. remove all strips below hardware threshold that do not have a neighboring TriggeredStrip
  3. create empty (energy = 0, small timing) MDEEStripHits for all NeighborCandidateStrips that were not created during MSubModuleChargeTransport

Here is a sketch to illustrate the logic behind the final loop:

[fhagemann]

In my last commit, I added a dummy hardware thresholds file, together with a corresponding dummy ecal.
It is important to use the hardware thresholds together with the correct ecal file, as the hardware thresholds in the DEE are applied in ADC units (which requires the conversion from keV -> ADC to be correct).

The "real" hardware threshold files are currently determined using the python tools by:

• creating energy histograms in ADC units for events with hit_type 0 (triggered)
• fitting the noise peak to the left of that distribution
• setting the hardware threshold at the peak position minus the FWHM/2 (half width at half maximum)

This, at some point, can be generated using the threshold app in #166.

[fhagemann]

With the changes in this PR, the DEE would require a hardware threshold file, or it wouldn't run.
I could also add the option to "just" pass a value for the hardware threshold instead of a file, so that people can easily set something if they don't care about main strip / NN classification.

[ckierans]

Is this currently marked as a draft because you're waiting on a decision on how to handle the required hardware threshold file? Your suggestion of adding a value for the hardware threshold as another option would make this easier, as you suggest, for folks who aren't interested in the thresholding performance, so I'd agree with that as a temporary plan as we wait for the hardware threshold files to be defined. Let me know when you'd like me to review this PR.

[fhagemann]

yes, marking as draft until we have correct files for the detectors.

This PR already has a dummy hardware threshold file added, which makes sense in combination with the dummy ecal (setting the threshold to 7 keV everywhere).
For „real“ ecals, I would not expect there to be a single-value hardware threshold. Therefore, I’m not sure if adding an extra option to pass a value is that helpful.

Feel free to review already now, but maybe wait with merging until we have a plan for generating the threshold files

[ckierans]

Looks like a good start, @fhagemann!

Can/should we have someone analyze the Unit Level data with the python tools to generate hardware threshold files for each detector? Seems like we'd want them to better bench mark the Unit Level data, even with the Payload Calibrations coming soon.

As stated previously, the goal will be to have the hardware thresholds determined through the Nuclearizer app, and then we can likely have one file that contains all thresholds, vs a separate HardwareThreshold file. But that's probably down the line...

[ckierans]

I'm wondering about the procedure for defining dead strips. Here you're basing it off of the ecal file, which probably isn't a bad guess. But I also think defining a csv file (or whatever format) which has the dead strips listed would be better for tracking and updating during the mission.

[fhagemann]

Yes, I’m working on that. This is the fix for the time being :)

[parshadkp]

Are the hits on the dead strips stored in the event? If so, is this true for real data?

[fhagemann]

The hits of the dead strips would NOT be saved in the DEE, because they do not have a valid energy calibration and then get discarded in MSubModuleStripReadout.
In data, events on dead strips would not appear in the first place.

One difference is though, that SHORTED strips might keep that information.
I opened an issue to keep track of shorted/double-wide strips (#157), and I also envision to handle dead strips in a similar way.

[parshadkp]

I should have phrased this better. The hits are passed onto other modules, which affects dead time. I am not sure if that is correct. Maybe we can ask about this tomorrow.

[fhagemann]

I see, you're talking about actually removing those strip hits instead of "just flagging them". I can look into this

[fhagemann]

I am removing strip hits on what's flagged as "dead strip" (no valid energy/depth calibration) --> da2275f

[parshadkp]

Sorry, I think you should leave them in. I can ignore them in the dead time calculation if need be as long as they have a flag associated with them. I will ask if they should be included in dead time calculation or not.

[fhagemann]

I plan to have a separate PR dealing with dead/shorted strips, so maybe we can leave this as is, and tackle this in the follow-up PR (?)

[parshadkp]

Sounds good!

[fhagemann]

I think @JarredMRoberts has made some progress with the threshold finding app in #166, so we can discuss on Tuesday whether we can use that one to generate the hardware threshold, or have Python-tools-generated ones for the transition period until the nuclearizer threshold finding app fits data from all detectors robustly

[parshadkp]

I tested the effect of this new PR190 with the changes from PR165 and PR173 on dead time. See images below for the comparisons. The results are as expected:

1. Similar but lower dead time than the NN hack from before PR165 due to hardware thresholds implementation.
2. More dead time compared to NN hack due to the NN cascaded strips if using thresholds set to 0.

I also reviewed the code and left a few small comments.

[parshadkp]

Are the hits on the dead strips stored in the event? If so, is this true for real data?

[fhagemann]

As discussed in the CDEE meeting on August 25, let's merge #173 together with this PR once this PR is approved.