coresoftware feat(MinimumBiasClassifier): Add PHParameters for detailed cut tracking

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work for users)
[ ] Requiring change in macros repository (Please provide links to the macros pull request in the last section)
[x] I am a member of GitHub organization of sPHENIX Collaboration, EIC, or ECCE (contact Chris Pinkenburg to join)

What kind of change does this PR introduce? (Bug fix, feature, ...)

This PR introduces PHParameters to the MinimumBiasClassifier to provide detailed, event-by-event information about why the minimum bias selection passes or fails. Previously, the module only set a single boolean, making it difficult to debug or perform quality assurance checks.

Key changes include:

A PHParameters object named "MinBiasParams" is now created and stored on the PAR node.
Individual boolean flags are set to true if an event fails a specific selection criterion, such as:
- minbias_background_cut_fail
- minbias_two_hit_min_fail
- minbias_zdc_energy_min_fail
- minbias_mbd_total_energy_max_fail
Key calculated values (e.g., MBD north/south charge, vertex scale) are also saved to this object for downstream analysis and QA.
The total MBD charge cut is no longer a hardcoded constant and can be configured via the new set_mbd_total_charge_cut() method. (Note: The default total MBD charge cut of 2100 remains unchanged.)

TODOs (if applicable)

Links to other PRs in macros and calibration repositories (if applicable)

Sep 19 '25 16:09 Steepspace

Build & test report

Report for commit 2af2be95566efb8e8f5eb2dda64ab85a79543791:

builds and tests overall are SUCCESS.
Build with configuration of alma9.2-gcc-14.2.0 / clang is SUCCESS, :bar_chart:clang report (full)/(new), build log
Build with configuration of alma9.2-gcc-14.2.0 / new is SUCCESS, :bar_chart:Compiler report (full)/(new), build log
- Generating DST and readback: build is SUCCESS
- Calorimeter QA: build is SUCCESS, :bar_chart: trends
  - :bar_chart: QA-calorimeter for e- at p_T=4GeV : combined Chi2/nDoF = 30.7534 / 72, and combined p-Value = 0.999995
  - :bar_chart: QA-calorimeter for pi+ at p_T=30GeV : combined Chi2/nDoF = 45.4076 / 72, and combined p-Value = 0.993985
  - :bar_chart: QA-calorimetric-jet for e- at p_T=4GeV : combined Chi2/nDoF = 0.0941228 / 42, and combined p-Value = 1
  - :bar_chart: QA-calorimetric-jet for pi+ at p_T=30GeV : combined Chi2/nDoF = 20.5358 / 42, and combined p-Value = 0.99784
- Tracking QA with Distortions: build is SUCCESS, :bar_chart: trends
  - :bar_chart: QA-distortions
- Tracking QA at low occupancy: build is SUCCESS, :bar_chart: trends
  - :bar_chart: QA-Intt : combined Chi2/nDoF = -0 / 72, and combined p-Value = 1
  - :bar_chart: QA-Micromegas : combined Chi2/nDoF = -0 / 20, and combined p-Value = 1
  - :bar_chart: QA-Mvtx : combined Chi2/nDoF = -0 / 54, and combined p-Value = 1
  - :bar_chart: QA-Tpc : combined Chi2/nDoF = -0 / 56, and combined p-Value = 1
  - :bar_chart: QA-tracking : combined Chi2/nDoF = -0 / 56, and combined p-Value = 1
  - :bar_chart: QA-vertexing : combined Chi2/nDoF = 30 / 112, and combined p-Value = 1
- Tracking QA for Pythia D0-jet: build is SUCCESS, :bar_chart: trends
  - :bar_chart: QA-Intt : combined Chi2/nDoF = -0 / 72, and combined p-Value = 1
  - :bar_chart: QA-Micromegas : combined Chi2/nDoF = -0 / 20, and combined p-Value = 1
  - :bar_chart: QA-Mvtx : combined Chi2/nDoF = -0 / 54, and combined p-Value = 1
  - :bar_chart: QA-Tpc : combined Chi2/nDoF = -0 / 56, and combined p-Value = 1
  - :bar_chart: QA-tracking : combined Chi2/nDoF = -0 / 50, and combined p-Value = 1
  - :bar_chart: QA-vertexing : combined Chi2/nDoF = 30 / 112, and combined p-Value = 1
- Tracking QA from run2pp 53877: build is SUCCESS, :bar_chart: trends
  - :bar_chart: QA-intt : combined Chi2/nDoF = -0 / 18, and combined p-Value = 1
  - :bar_chart: QA-micromegas : combined Chi2/nDoF = -0 / 6, and combined p-Value = 1
  - :bar_chart: QA-mvtx : combined Chi2/nDoF = -0 / 18, and combined p-Value = 1
  - :bar_chart: QA-siliconseeds : combined Chi2/nDoF = 14.0144 / 20, and combined p-Value = 0.829766
  - :bar_chart: QA-tpc : combined Chi2/nDoF = -0 / 48, and combined p-Value = 1
  - :bar_chart: QA-tpcseeds : combined Chi2/nDoF = 0.0240223 / 28, and combined p-Value = 1
  - :bar_chart: QA-trackfit : combined Chi2/nDoF = 38.6388 / 32, and combined p-Value = 0.194715
- system alma9.2-gcc-14.2.0, build new: run the default sPHENIX macro: build is SUCCESS, output, trends :bar_chart:
- system alma9.2-gcc-14.2.0, build new: run the default CaloProduction/Fun4All_Year2.C macro: build is SUCCESS, output, trends :bar_chart:
- system alma9.2-gcc-14.2.0, build new: run the default StreamingProduction/Fun4All_Stream_Combiner.C macro: build is SUCCESS, output, trends :bar_chart:
- system alma9.2-gcc-14.2.0, build new: Valgrind test of CaloProduction/Fun4All_Year2.C: build is SUCCESS, :bar_chart:valgrind report, trends :bar_chart:
- system alma9.2-gcc-14.2.0, build new: Valgrind test of StreamingProduction/Fun4All_Stream_Combiner.C: build is SUCCESS, :bar_chart:valgrind report, trends :bar_chart:
- system alma9.2-gcc-14.2.0, build new: run the overlap check for sPHENIX macro: build is SUCCESS, output
- system alma9.2-gcc-14.2.0, build new: Valgrind test: build is SUCCESS, :bar_chart:valgrind report, trends :bar_chart:
Build with configuration of alma9.2-gcc-14.2.0 / scan is SUCCESS, :bar_chart:scan-build report (full)/(new), build log
clang-tidy is SUCCESS, :bar_chart:clang-tidy report (full)/(new)
cpp-check is SUCCESS, :bar_chart:cppcheck report (full)/(new)

Automatically generated by sPHENIX Jenkins continuous integration

Sep 20 '25 05:09 sphenix-jenkins-ci[bot]

PHParameters are very expensive to use on an event by event basis. They are meant to be used for configurations and have a DB backend. This is just the wrong class to handle event by event parameters in this case,

Sep 20 '25 18:09 pinkenburg

PHParameters are very expensive to use on an event by event basis. They are meant to be used for configurations and have a DB backend. This is just the wrong class to handle event by event parameters in this case,

I will note that PHParameters is currently used in the JetBackgroundCut module that also does something similar on an event by event basis: https://github.com/sPHENIX-Collaboration/coresoftware/blob/9d03281ebaecd5e37e533df03e9836e73602d5aa/offline/packages/jetbackground/JetBackgroundCut.cc#L283-L293

However, since this is not recommended, do you suggest any other approach that will be ideal to pass the information regarding the cuts so that QA downstream can log that different cases?

Sep 20 '25 18:09 Steepspace

That was a bit of a temporary measure - before that they used PHFlag which is even worse. The very basic problem here (and in the jet background) is that it uses the temporary "PAR" which is not saved (and also not reset - so there is a possibility of carrying information from one event to the next accidentally). That means the downstream qa module can never be run off a DST which is just a bad idea (and it will potentially read info from a previous event). I don't see any qa code which accesses this node - so I am not sure if this was actually thought out or followed up with an actual qa implementation. What we probably need is some dumb i/o class with an int and double vector and then have accessors for each implementation which just look values up via index and store this thing under the DST node .

Sep 20 '25 19:09 pinkenburg

What we probably need is some dumb i/o class with an int and double vector and then have accessors for each implementation which just look values up via index and store this thing under the DST node

Thank you for the suggestion. Could you provide a template or reference that I can use to implement this i/o class that can store these quantities under the DST node? In the meantime, please feel free to mark this PR back to Draft since it's not acceptable at this stage.

Sep 20 '25 22:09 Steepspace