Skip to content

2024A Veto stability

Following the pass2 reconstruction of the 2024A electron data, I wanted to evaluate the veto stability throughout the whole 2024A data-taking. To do that, I used the Veto cut as defined for the 2023A electron period analysis, and evaluated its run-by-run efficiency. The 2023 veto cut was defined as follows:

bool filterVETO(RVecD &VETO_enePMT) {
  const double vetoCut01 = 0.0076;
  const double vetoCut23 = 0.008;
  const double vetoCut45 = 0.0076;

  double eVETO01 = VETO_enePMT[0] + VETO_enePMT[1];
  double eVETO23 = VETO_enePMT[2] + VETO_enePMT[3];
  double eVETO45 = VETO_enePMT[4] + VETO_enePMT[5];

  return ((eVETO01 < vetoCut01) && (eVETO23 < vetoCut23) && (eVETO45 < vetoCut45));
}

The Veto To evaluate its efficiency I selected beamOnly events and applied the following cuts:

auto dF2 = dF1.Filter("abs(mom_genfit_upMM-100)<20"); 
auto dF3 = dF2.Filter("eecal > 80 && eecal < 120");
auto dF4 = dF3.Filter("ehcal < 10");
auto dF5 = dF4.Filter(filterSRD, {"SRD_ene"});
auto dF6 = dF5.Filter(filterVETO, {"VETO_enePMT"});

The used SRD cuts is inherited by the 2023A analysis. For the moment, I chose not to use the in-time variables. The results are reported below: Screenshot_2025-07-25_alle_10.58.53 Screenshot_2025-07-25_alle_10.59.10 image Screenshot_2025-07-25_alle_11.00.13 image

The two fluctuation in period 4 are respectively due to:

  • A change of the DAQ dead time occurring during runs 11126-11128
  • A reported "veto instability" due to hardware issues (the HV board for the LYSO detector was causing troubles - the veto instability was resolved by simply turning the LYSO board off).
Edited by Anna Marini
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information