StripEnergyThresholdFinder for per-strip slow and fast threshold extraction with diagnostics by JarredMRoberts · Pull Request #166 · cositools/nuclearizer

JarredMRoberts · 2026-06-23T05:33:43Z

Adds a standalone application, StripEnergyThresholdFinder, for computing per-strip slow and fast energy thresholds. Slow thresholds are determined from ADC spectra using a noise peak and trough method, while fast thresholds are determined from dt0/dt1 timing crossover. The tool reads calibrated HDF5 data via MModuleLoaderMeasurementsHDF, applies strip mapping and energy calibration from a YAML configuration, and produces ROOT diagnostic outputs (energy spectra with thresholds, dt0 vs dt1 per strip, and threshold distributions) along with CSV export files. The implementation is self-contained under apps/ and does not modify existing modules. Tested on COSI datasets with consistent threshold behavior and expected diagnostic results. Target branch is develop/em.

…extraction

JarredMRoberts · 2026-06-23T06:55:33Z

I still need to fix all of the code style issues and work on some optimizations to speed the code up a bit.

fhagemann · 2026-06-23T20:55:00Z

Is this different from #143 or making #143 obsolete?

fhagemann · 2026-06-23T20:59:07Z

+struct StripKey
+{
+  int det;
+  char side;
+  int strip;
+
+  bool operator<(const StripKey& o) const
+  {
+    if(det!=o.det) return det<o.det;
+    if(side!=o.side) return side<o.side;
+    return strip<o.strip;
+  }
+};


Can you not reuse the code from MStripMap.cxx here?

Good point. I checked MStripMap, but it looks to me like it's centered on ReadOutID lookups. I’m currently using a local StripKey for (det, side, strip) grouping. It made more sense to me to think of the strip mapping from a detector -> side -> strip direction, especially when reviewing the code. I'd be happy to adjust it if we want to prioritize tighter integration.

Isn't that functionality exactly what MReadOutElementDoubleStrip does?

I did take a look at MReadOutElementDoubleStrip, and it looks like it's doing something similar (detector, strip, side), but it also looks like it's part of the MReadOutElement hierarchy, and it includes additional things (parsing, cloning, comparing objects) that we don't need here. We only need a quick identifier to group histogram data as a key in a container. It seems like using MReadOutElementDoubleStrip could bring in additional dependencies that complicate things. If there's a preferred way to represent strip identifiers in this context, then I'd be more than happy to try to figure it out. Let me know!

This can indeed be replaced by MReadOutElementDoubleStrip. I opened a PR onto your branch, where one of the commits replaces StripKey by MReadOutElementDoubleStrip.

fhagemann · 2026-06-23T21:00:05Z

+class EnergyCalHelper
+{
+public:
+
+  struct Coeff
+  {
+    double c0=0;
+    double c1=0;
+    double c2=0;
+    double c3=0;
+  };
+
+  bool Load(const string& fileName,int nDet=64,int nStrip=65)
+  {
+    m_NDet=nDet;
+    m_NStrip=nStrip;
+
+    m_Coeffs.resize(m_NDet);
+
+    for(int d=0;d<m_NDet;d++)
+    {
+      m_Coeffs[d].resize(2);
+
+      for(int s=0;s<2;s++)
+        m_Coeffs[d][s].resize(m_NStrip);
+    }
+
+    ifstream in(fileName);
+
+    if(!in)
+    {
+      cout<<"Unable to open calibration file "<<fileName<<endl;
+      return false;
+    }
+
+    string line;
+
+    while(getline(in,line))
+    {
+      if(line.empty()) continue;
+
+      stringstream ss(line);
+
+      string tag;
+      ss>>tag;
+
+      if(tag!="CM") continue;
+
+      string unused;
+      int det=-1;
+      int strip=-1;
+      string side;
+      string order;
+
+      ss>>unused>>det>>strip>>side>>order;
+
+      if(det<0||det>=m_NDet) continue;
+      if(strip<0||strip>=m_NStrip) continue;
+
+      int sideInt=(side=="l")?0:1;
+
+      Coeff c;
+
+      if(order=="poly1zero")
+        ss>>c.c1;
+      else if(order=="poly1")
+        ss>>c.c0>>c.c1;
+      else if(order=="poly2")
+        ss>>c.c0>>c.c1>>c.c2;
+      else
+        ss>>c.c0>>c.c1>>c.c2>>c.c3;
+
+      m_Coeffs[det][sideInt][strip]=c;
+    }
+
+    return true;
+  }
+
+  double ADCToEnergy(int det,char side,int strip,double adc) const
+  {
+    int sideInt=(side=='l')?0:1;
+    const Coeff& c=m_Coeffs[det][sideInt][strip];
+
+    return c.c3*pow(adc,3)+c.c2*pow(adc,2)+c.c1*adc+c.c0;
+  }
+
+private:
+
+  int m_NDet;
+  int m_NStrip;
+
+  vector<vector<vector<Coeff>>> m_Coeffs;
+};


This essentially does what MModuleEnergyCalibration does.
Can you create a MModuleEnergyCalibration variable in this app and use its functions here to avoid code duplication and keep the code for this app short?

Yes. I wrote the threshold app to be standalone, not requiring the full MSupervisor pipeline for calibration, so I built a lightweight calibration helper for direct ADC-to-energy conversion to occur within the app. But, it definitely duplicates functionality found in MModuleEnergyCalibration. I'll refactor the app to use the standard module chain.

Alright, so I worked on integrating MModuleEnergyCalibration into the event processing, and right now it's being used to calibrate the strip hits (AnalyzeEvent and SH->GetEnergy()). It worked just fine, there. I also took a look at replacing EnergyCalHelper entirely, but I ran into some issues that broke things. In this app we're mostly operating on histogrammed data (ADC counts), not individual hits within an event. At a basic level, we just need to convert arbitrary ADC values into keV (like when we need to determine thresholds or set histogram axes), and not just values associated with a specific hit. The MModule applies calibration within the event, but it doesn't seem to provide a way to convert the ADC values outside of the event context. So, I think it might be best to keep EnergyCalHelper for now to perform those conversions, while using the MModule for all event-level calibration. If there is a more "MEGAlib" way to handle the quick ADC to keV conversions outside of the event-level pipeline, I'd be happy to look into that!

Same thing here: check out the PR JarredMRoberts#1 onto your branch, that replaces EnergyCalHelper with the MModuleEnergyCalibration functionality, outside of the event-level pipeline.

fhagemann · 2026-06-23T21:01:49Z

+class TACCalHelper
+{
+public:
+
+  struct Coeff
+  {
+    double slope = 0;
+    double offset = 0;
+  };
+
+  bool Load(const string& fileName)
+  {
+    ifstream in(fileName);
+    if(!in)
+    {
+      cout<<"Failed to open TAC calibration file: "<<fileName<<endl;
+      return false;
+    }
+
+    string line;
+    getline(in,line); // skip header
+
+    while(getline(in,line))
+    {
+      if(line.empty()) continue;
+
+      stringstream ss(line);
+
+      int strip_id, det, side, strip;
+      double slope, slope_err, offset, offset_err;
+
+      ss >> strip_id >> det >> side >> strip
+         >> slope >> slope_err >> offset >> offset_err;
+
+      char sideChar = (side==0) ? 'l' : 'h';
+
+      StripKey key{det, sideChar, strip};
+
+      m_Coeffs[key] = {slope, offset};
+    }
+
+    return true;
+  }
+
+  double TACToEnergy(int det, char side, int strip, double tac) const
+  {
+    StripKey key{det, side, strip};
+
+    auto it = m_Coeffs.find(key);
+    if(it == m_Coeffs.end()) return 0;
+
+    return it->second.slope * tac + it->second.offset;
+  }
+
+private:
+  map<StripKey, Coeff> m_Coeffs;
+};


This already exists in MModuleTACcut --> use existing class to avoid code duplication here.

I took another close look at MModuleTACCut. This issue I'm running into is that this requires both a TAC Calibration file and a TAC cut file to run smoothly. It's also performing event filtering as part of its operation. For the threshold finding app, I'd prefer that we only use the TAC calibration file as an input, and I'd like to avoid applying any TAC cuts to the data in order to find the fast shaper thresholds. I did attempt to see if I could figure out a workaround to trick MModuleTACCut into thinking it was receiving a TAC cut file with arbitrarily low values, but this ended up being a bit odd. I'd prefer to use the simple TACCalHelper I've written instead.

It looks like TACCalHelper is never used. I believe for this app you don't need to calibrate TAC values, you just care if a strip had FastTiming or not. So, I believe this whole thing can go.

fhagemann · 2026-06-23T21:03:11Z

+private:
+
+  // --- Configuration ---
+  EnergyCalHelper m_EnergyCal;


Suggested change

EnergyCalHelper m_EnergyCal;

MModuleEnergyCalibration m_EnergyCal;

MModuleEnergyCalibration is now being used for the event-level calibration but since this code operates on histogram ADC data, we still need a way to convert arbitrary AC values to keV outside of the event-level data. I'd prefer to keep EnergyCalHelper for this reason.

You can convert arbitrary ADC values to keV outside of the event-level data, by just using MModuleEnergyCalibration::GetEnergy instead of EnergyCalHelper::ADCToEnergy, which essentially does the same thing.

fhagemann · 2026-06-23T21:05:40Z

+
+
+  //EnergyCalHelper m_EnergyCal;
+  TACCalHelper m_EnergyCal_TAC;


That's a weird name, is Energy intended in this name? I would just call it m_TACCal.. And if it's called m_..., consider making this a (private) member variable of the class -- just like m_EnergyCal

Also: where is this TACCalHelper ever used?

Ugh, good point. It's a bad name, and it isn't actually used anywhere :|

It's removed now.

fhagemann · 2026-06-23T21:06:58Z

+  //EnergyCalHelper m_EnergyCal;
+  TACCalHelper m_EnergyCal_TAC;
+
+  if(!m_EnergyCal.Load(m_CalibrationFile.Data()))


MModuleEnergyCalibration has a ReadEnergyCalibrationFile function that you could call here instead:

Suggested change

if(!m_EnergyCal.Load(m_CalibrationFile.Data()))

if (m_EnergyCal.ReadEnergyCalibrationFile(m_CalibrationFile) == false)

Based on the comments above about how I'd like to keep the EnergyCalHelper for ADC to keV conversions in histogrammed data outside of the event context, let's keep this one as it is if that's ok.

See my PR JarredMRoberts#1 to see how this can still be achieved without the need of EnergyCalHelper.

fhagemann · 2026-06-23T21:10:21Z

+  EnergyCalHelper m_EnergyCal;
+  vector<string> m_InputFiles;
+  MString m_CalibrationFile;
+  MString m_TACCalibrationFile;


This seems to never be used.

Hm, I'm seeing that only m_TACCalibrationFile is no longer being used. I can't remember what it used to be a part of, but it can be removed now. It looks like the other ones are being used for histogram building and ADC conversion.

See comment above: I don't think that you are applying any TAC calibration or TAC cuts, so this can be safely removed (or the code to calibrate TAC values from ADC units to ns still needs to be added).

Co-authored-by: Felix Hagemann <hagemann@berkeley.edu>

…nventions and integrate energy calibration improvements

fhagemann · 2026-07-28T18:15:41Z

+#include <chrono>
+
+/* YAML */
+#include <yaml-cpp/yaml.h>


I had to add -lyaml-cpp to ALLLIBS in the Makefile to compile this app:

nuclearizer/Makefile

Line 119 in 1a1b3ee

ALLLIBS = -L$(LB) -lResponseCreator -lFretalonBase -lSivan -lRevanGui -lRevan -lMimrec -lGeomega -lSpectralyzeGui -lSpectralyze -lCommonMisc -lCommonGui -L$(MEGALIB)/lib -L$(LB)

Is there an alternative to running this app without depending on YAML? 😇

But even if it compiled, running StripEnergyThresholdFinder $NUCLEARIZER/apps/StripEnergyThresholdFinder_config.yaml resulted in the following error:

terminate called after throwing an instance of 'YAML::TypedBadConversion<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >' what(): bad conversion Aborted (core dumped)

The error I posted went away once the mismatch in capitalization between strip_map in the config.yaml and parsing Strip_map in the app was resolved :)

fhagemann

Hi Jarred,
I had an extensive look at this app and finally got this to run.
I replied to all comments in this PR, and opened a separate PR onto your fork/branch, addressing some code changes to

get this app running
remove the helper classes by replacing them with existing nuclearizer/megalib code

Here is the PR onto your branch with detailed code changes: JarredMRoberts#1

fhagemann · 2026-08-10T16:27:18Z

+
+
+  m_CalibrationFile = config["input"]["calibration_file"].as<string>().c_str();
+  m_StripMapFile = config["input"]["Strip_map"].as<string>().c_str();


This is what broke my code:

Suggested change

m_StripMapFile = config["input"]["Strip_map"].as<string>().c_str();

m_StripMapFile = config["input"]["strip_map"].as<string>().c_str();

You might need to add specific guards here to make sure that the fields in the YAML file exist, before trying to parse it.
Or avoid YAML completely and write your own custom parser here.

fhagemann · 2026-08-10T16:27:55Z

+#include <chrono>
+
+/* YAML */
+#include <yaml-cpp/yaml.h>


The error I posted went away once the mismatch in capitalization between strip_map in the config.yaml and parsing Strip_map in the app was resolved :)

fhagemann · 2026-08-10T16:29:01Z

+struct StripKey
+{
+  int det;
+  char side;
+  int strip;
+
+  bool operator<(const StripKey& o) const
+  {
+    if(det!=o.det) return det<o.det;
+    if(side!=o.side) return side<o.side;
+    return strip<o.strip;
+  }
+};


This can indeed be replaced by MReadOutElementDoubleStrip. I opened a PR onto your branch, where one of the commits replaces StripKey by MReadOutElementDoubleStrip.

fhagemann · 2026-08-10T16:29:57Z

+class EnergyCalHelper
+{
+public:
+
+  struct Coeff
+  {
+    double c0=0;
+    double c1=0;
+    double c2=0;
+    double c3=0;
+  };
+
+  bool Load(const string& fileName,int nDet=64,int nStrip=65)
+  {
+    m_NDet=nDet;
+    m_NStrip=nStrip;
+
+    m_Coeffs.resize(m_NDet);
+
+    for(int d=0;d<m_NDet;d++)
+    {
+      m_Coeffs[d].resize(2);
+
+      for(int s=0;s<2;s++)
+        m_Coeffs[d][s].resize(m_NStrip);
+    }
+
+    ifstream in(fileName);
+
+    if(!in)
+    {
+      cout<<"Unable to open calibration file "<<fileName<<endl;
+      return false;
+    }
+
+    string line;
+
+    while(getline(in,line))
+    {
+      if(line.empty()) continue;
+
+      stringstream ss(line);
+
+      string tag;
+      ss>>tag;
+
+      if(tag!="CM") continue;
+
+      string unused;
+      int det=-1;
+      int strip=-1;
+      string side;
+      string order;
+
+      ss>>unused>>det>>strip>>side>>order;
+
+      if(det<0||det>=m_NDet) continue;
+      if(strip<0||strip>=m_NStrip) continue;
+
+      int sideInt=(side=="l")?0:1;
+
+      Coeff c;
+
+      if(order=="poly1zero")
+        ss>>c.c1;
+      else if(order=="poly1")
+        ss>>c.c0>>c.c1;
+      else if(order=="poly2")
+        ss>>c.c0>>c.c1>>c.c2;
+      else
+        ss>>c.c0>>c.c1>>c.c2>>c.c3;
+
+      m_Coeffs[det][sideInt][strip]=c;
+    }
+
+    return true;
+  }
+
+  double ADCToEnergy(int det,char side,int strip,double adc) const
+  {
+    int sideInt=(side=='l')?0:1;
+    const Coeff& c=m_Coeffs[det][sideInt][strip];
+
+    return c.c3*pow(adc,3)+c.c2*pow(adc,2)+c.c1*adc+c.c0;
+  }
+
+private:
+
+  int m_NDet;
+  int m_NStrip;
+
+  vector<vector<vector<Coeff>>> m_Coeffs;
+};


Same thing here: check out the PR JarredMRoberts#1 onto your branch, that replaces EnergyCalHelper with the MModuleEnergyCalibration functionality, outside of the event-level pipeline.

fhagemann · 2026-08-10T16:30:54Z

+class TACCalHelper
+{
+public:
+
+  struct Coeff
+  {
+    double slope = 0;
+    double offset = 0;
+  };
+
+  bool Load(const string& fileName)
+  {
+    ifstream in(fileName);
+    if(!in)
+    {
+      cout<<"Failed to open TAC calibration file: "<<fileName<<endl;
+      return false;
+    }
+
+    string line;
+    getline(in,line); // skip header
+
+    while(getline(in,line))
+    {
+      if(line.empty()) continue;
+
+      stringstream ss(line);
+
+      int strip_id, det, side, strip;
+      double slope, slope_err, offset, offset_err;
+
+      ss >> strip_id >> det >> side >> strip
+         >> slope >> slope_err >> offset >> offset_err;
+
+      char sideChar = (side==0) ? 'l' : 'h';
+
+      StripKey key{det, sideChar, strip};
+
+      m_Coeffs[key] = {slope, offset};
+    }
+
+    return true;
+  }
+
+  double TACToEnergy(int det, char side, int strip, double tac) const
+  {
+    StripKey key{det, side, strip};
+
+    auto it = m_Coeffs.find(key);
+    if(it == m_Coeffs.end()) return 0;
+
+    return it->second.slope * tac + it->second.offset;
+  }
+
+private:
+  map<StripKey, Coeff> m_Coeffs;
+};


It looks like TACCalHelper is never used. I believe for this app you don't need to calibrate TAC values, you just care if a strip had FastTiming or not. So, I believe this whole thing can go.

fhagemann · 2026-08-10T16:31:58Z

+private:
+
+  // --- Configuration ---
+  EnergyCalHelper m_EnergyCal;


You can convert arbitrary ADC values to keV outside of the event-level data, by just using MModuleEnergyCalibration::GetEnergy instead of EnergyCalHelper::ADCToEnergy, which essentially does the same thing.

fhagemann · 2026-08-10T16:32:40Z

+  EnergyCalHelper m_EnergyCal;
+  vector<string> m_InputFiles;
+  MString m_CalibrationFile;
+  MString m_TACCalibrationFile;


See comment above: I don't think that you are applying any TAC calibration or TAC cuts, so this can be safely removed (or the code to calibrate TAC values from ADC units to ns still needs to be added).

fhagemann · 2026-08-10T16:33:16Z

+  //EnergyCalHelper m_EnergyCal;
+  TACCalHelper m_EnergyCal_TAC;
+
+  if(!m_EnergyCal.Load(m_CalibrationFile.Data()))


See my PR JarredMRoberts#1 to see how this can still be achieved without the need of EnergyCalHelper.

fhagemann · 2026-08-10T17:15:28Z

+      line->Draw("SAME");
+
+      // Legend entry (fix from earlier)
+      leg->AddEntry(line, "Fast Thresholdeshold", "l");


Suggested change

leg->AddEntry(line, "Fast Thresholdeshold", "l");

leg->AddEntry(line, "Fast Threshold", "l");

fhagemann · 2026-08-17T20:44:53Z

+#include <chrono>
+
+/* YAML */
+#include <yaml-cpp/yaml.h>


After reviewing #184: Please remove the YAML dependency.

I would strongly suggest that we pass the required parameters either via terminal command options (see #184 for example), or via a custom file format with a custom parser. But in my opinion, it is an overkill to add the YAML dependency to nuclearizer and requiring it in the make process just for this app (also for users who might not even need to run this app).

zoglauer · 2026-08-17T21:09:02Z

I second not to have an additional parser linked.
You can use the nuclearizer/megalib XML file format instead; your file then would be:

<strip-threshold-finder>
    <input>
        <data_files>
            <file>/path/to/data/file.hdf5</file>
        </data_files>
        <calibration_file>/path/to/calibration/file.ecal</calibration_file>
        <tac_calibration_file>/path/to/tac/calibration/file.csv</tac_calibration_file>
        <strip_map>/path/to/strip/map/file.map</strip_map>
    </input>

    <analysis>
        <!-- number of skipped strips with minimum statistics -->
        <min_entries>10</min_entries> 
        
        <!-- If a threshold cannot be determined set threshold to default value -->
        <fallback_threshold_keV>20</fallback_threshold_keV> 
        
        <!-- limit for locating the low-energy noise peak -->
        <!-- most noise peaks should be between 100 and 250 -->
        <!-- Worst case the ADC max should be set to ~1000 -->
        <noise_search_max_adc>1800</noise_search_max_adc>
    </analysis>
    
    <output>
        <prefix>output_file_prefix</prefix>
    </output>
</strip-threshold-finder>

fhagemann

One more remark: I got this app to run and got reasonable results for the fast and slow thresholds only when using a dataset taken with NN off.
We might want to always filter out NN events, for this app to also run using datasets taken with NN on.

fhagemann · 2026-08-17T22:00:51Z

+  MModuleLoaderMeasurementsHDF* Loader = new MModuleLoaderMeasurementsHDF();
+
+  Loader->SetFileName(m_InputFiles[0].c_str());
+
+  cout << "Loading file: " << m_InputFiles[0] << endl;
+  cout << "Number of input files: " << m_InputFiles.size() << endl;
+
+  Loader->SetFileNameStripMap(m_StripMapFile.Data());


This app only works when using a dataset where NN was off.
If NN was on, we might require filtering those NN events out for later analysis by adding
Loader->SetIncludeNearestNeighbor(false);:

Suggested change

MModuleLoaderMeasurementsHDF* Loader = new MModuleLoaderMeasurementsHDF();

Loader->SetFileName(m_InputFiles[0].c_str());

cout << "Loading file: " << m_InputFiles[0] << endl;

cout << "Number of input files: " << m_InputFiles.size() << endl;

Loader->SetFileNameStripMap(m_StripMapFile.Data());

MModuleLoaderMeasurementsHDF* Loader = new MModuleLoaderMeasurementsHDF();

Loader->SetFileName(m_InputFiles[0].c_str());

cout << "Loading file: " << m_InputFiles[0] << endl;

cout << "Number of input files: " << m_InputFiles.size() << endl;

Loader->SetFileNameStripMap(m_StripMapFile.Data());

Loader->SetIncludeNearestNeighbor(false);

Using gse_20260217T115220.hdf5:

Current state, not filtering NN events:

Slow thresholds Example energy spectrum (HV10)

Filtering NN events:

Slow thresholds Example energy spectrum (HV10)

For some strips, the app still seems to pick up the wrong "noise peak" in NN-on datasets, after filtering NN events:

…nges from Felix

JarredMRoberts added 2 commits June 1, 2026 18:15

Add StripEnergyThresholdFinder app

6dc7104

Add StripEnergyThresholdFinder for per-strip slow and fast threshold …

2f699ef

…extraction

fhagemann reviewed Jun 23, 2026

View reviewed changes

fhagemann requested changes Jun 23, 2026

View reviewed changes

Comment thread apps/StripEnergyThresholdFinder.cxx Outdated

fhagemann marked this pull request as draft June 23, 2026 21:50

JarredMRoberts and others added 3 commits June 30, 2026 07:33

Update apps/StripEnergyThresholdFinder.cxx

dc2f2fb

Co-authored-by: Felix Hagemann <hagemann@berkeley.edu>

Update apps/StripEnergyThresholdFinder.cxx

808ad18

Co-authored-by: Felix Hagemann <hagemann@berkeley.edu>

Revision of StripEnergyThresholdFinder in-line with MEGAlib coding co…

a78bc0c

…nventions and integrate energy calibration improvements

JarredMRoberts marked this pull request as ready for review July 28, 2026 08:40

fhagemann reviewed Jul 28, 2026

View reviewed changes

fhagemann reviewed Aug 10, 2026

View reviewed changes

fhagemann mentioned this pull request Aug 12, 2026

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

Draft

fhagemann requested changes Aug 17, 2026

View reviewed changes

fhagemann reviewed Aug 17, 2026

View reviewed changes

ckierans mentioned this pull request Aug 18, 2026

Determine hardware threshold in Nuclearizer App #195

Open

Save working threshold finder implementation before merging other cha…

747ebbc

…nges from Felix

	EnergyCalHelper m_EnergyCal;
	MModuleEnergyCalibration m_EnergyCal;

	if(!m_EnergyCal.Load(m_CalibrationFile.Data()))
	if (m_EnergyCal.ReadEnergyCalibrationFile(m_CalibrationFile) == false)



		m_CalibrationFile = config["input"]["calibration_file"].as<string>().c_str();
		m_StripMapFile = config["input"]["Strip_map"].as<string>().c_str();

	leg->AddEntry(line, "Fast Thresholdeshold", "l");
	leg->AddEntry(line, "Fast Threshold", "l");

Uh oh!

Conversation

JarredMRoberts commented Jun 23, 2026

Uh oh!

JarredMRoberts commented Jun 23, 2026

Uh oh!

fhagemann commented Jun 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JarredMRoberts Jul 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JarredMRoberts Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fhagemann Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fhagemann Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fhagemann Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fhagemann left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fhagemann Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

JarredMRoberts Jul 28, 2026 •

edited

Loading

JarredMRoberts Jul 14, 2026 •

edited

Loading

fhagemann Aug 10, 2026 •

edited

Loading

fhagemann Aug 10, 2026 •

edited

Loading

fhagemann Aug 10, 2026 •

edited

Loading

fhagemann left a comment •

edited

Loading

fhagemann Aug 10, 2026 •

edited

Loading

fhagemann Aug 10, 2026 •

edited

Loading

fhagemann Aug 10, 2026 •

edited

Loading

zoglauer commented Aug 17, 2026 •

edited

Loading

fhagemann Aug 17, 2026 •

edited

Loading

fhagemann Aug 17, 2026 •

edited

Loading