Uninitialized entries in HcalVeto

[EinarElen]

I was noticing that I was seeing events where the HcalVeto contents looked really suspicious. In particular, the maxPEHit would look like it just contained junk, e.g

HcalHit { id: 8fe,  energy: -3.90105e-13MeV, time: 4.58477e-41ns, amplitude: 1.12104e-44, pe: 1.02773e-09}

Which looks a lot like uninitialized memory.

It looks like this happens when there are very few HcalRecHits (so far always 1) so I'm suspecting that the culprit is

  float maxPE{-1000};
  const ldmx::HcalHit *maxPEHit;
  for (const ldmx::HcalHit &hcalHit : hcalRecHits) {
    // If the hit time is outside the readout window, don't consider it.
    if (hcalHit.getTime() >= maxTime_) continue;

    // If the hit z position is beyond the maximum HCal depth, skip it.
    if (hcalHit.getZPos() > maxDepth_) continue;

    // Get the total PE in the bar
    float pe = hcalHit.getPE();
   ...
       if ((id.section() == ldmx::HcalID::BACK) && (hcalHit.getMinPE() < minPE_))
      continue;

       // Find the maximum PE in the list
    if (maxPE < pe) {
      maxPE = pe;
      maxPEHit = &hcalHit;
    }

   

So, if the only hcal hit is a stray hit of some kind, which either is at z> max, time > max, or is in the back with minPE is 0 we will never reach the maxPEHit = &hcalHit line and the maxPEHit will contain uninitialized memory.

[EinarElen]

This should be relatively straight-forward to fix by just changing const ldmx::HcalHit *maxPEHit; to start out as a nullptr, which we can check after the loop.

What is our typical approach to handling situations like this w.r.t. the event? Do we skip adding an entry or do we add some kind of defaulted veto hit that fails? @cmantill what do you think?

[EinarElen]

Closed by #70