coresoftware Improvements to sEPD software

This PR adds support for applying the sEPD calibration in CaloTowerCalib and for adding the sEPD geometry to the node tree using the RawTowerGeomContainer, in keeping with the conventions followed by calorimeter software.

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work for users)
[x] 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, ...)

As discussed at the BulkTG meeting: https://indico.bnl.gov/event/29269/ Note that this requires the calibrations file to use the tower key to index channels.

TODOs (if applicable)

Consider moving sEPDGeomMapping functionality into CaloGeomMapping. Change sEPD calibration files to store (1/MPV) rather than MPV so that no special cases are needed in CaloTowerCalib.

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

Corresponding changes in production macros at this PR: https://github.com/sPHENIX-Collaboration/macros/pull/1176

Aug 15 '25 15:08 largewedge

The changes to calotowercalib seem largely unnecessary and undesirable.
I am fine with changing isNoCalib to be applied to all calibrations <= 0 for all subsystems.

But can you just use the convention for the CDB tree name already in place? Putting in this code just because this is the BDC tree already in the CDB is just laziness and add to code bloat.

I fully support integrating the EPD into the main calo software but the whole point is to not use a bunch of flags for EPD when avoidable.

if I am looking at this right you should only need to change a line or two of calotowercalib.

Aug 15 '25 17:08 bseidlit

@bseidlit Agreed. I have reverted those changes. I will fix the calibration file to use the expected convention

Aug 15 '25 17:08 largewedge

I have some significant technical concerns about the proposed changes to retire EpdReco and replace it with sEPDGeomMapping:

Architectural Issues: The current approach introduces unnecessary complexity by duplicating geometry calculations. The workflow now becomes: copy phi, r, z values from EpdReco into sEPDGeomMapping with hardcoded phi values → convert to Cartesian coordinates → store in RawTowerGeomv1 → recalculate phi in downstream EventPlaneReco code. This circular conversion adds computational overhead and potential precision loss without clear benefit.

Geometric Modeling Concerns: The EPD detector has a disk geometry, which differs fundamentally from cylindrical calorimeter geometries. The existing EpdGeom class was specifically designed to handle the r, φ, z coordinate system appropriate for disk detectors. Forcing EPD into the calorimeter tower model is precisely why the geometry functionality had to be duplicated from EpdReco into the new sEPDGeomMapping class - it's an indication that we're working against the natural geometry rather than with it.

Simulation Impact: The proposed changes would retire the EpdGeom class, which is currently used by simulation code. This creates a significant risk of breaking existing simulation workflows that depend on the current geometry implementation.

Recommendation: Before proceeding with this major refactoring, I suggest we: Evaluate whether the benefits of calorimeter-style geometry justify the added complexity and code duplication Ensure simulation compatibility is maintained throughout any transition Consider a phased migration approach that preserves existing functionality

Aug 15 '25 18:08 eumaka

I do not completely disagree with @eumaka --I definitely think that whether the sEPD geometry handling should be done in CaloGeomMapping or in its own, separate module is worth further discussion, since CaloGeomMapping does seem to assume a cylindrical geometry; however, I do think that it's worthwhile to adhere more closely to the conventions set by the calorimeters, which would mean using RawTowerGeom objects when possible.

Note that RawTowerGeomv1 itself does not assume anything about the geometry of the detector: it allows us to use cartesian coordinates to locate towers (https://github.com/sPHENIX-Collaboration/coresoftware/blob/dd264ae362a1b9f3d60aacd945552bc1258c6ca5/offline/packages/CaloBase/RawTowerGeomv1.h#L44 ), which should be as inexpensive as storing arm, ring, phi. Either way, we store three values.

Regarding the workflow: the first step ("copy phi, r, z values from EpdReco into sEPDGeomMapping with hardcoded phi values") was a part of the process of refactoring itself and will not be done every time the code is run, so this does not add anything to the computational cost. The remaining steps contribute a marginal amount of additional computing time and are done in other calorimeters without issue (for example, the HCal: https://github.com/sPHENIX-Collaboration/coresoftware/blob/dd264ae362a1b9f3d60aacd945552bc1258c6ca5/simulation/g4simulation/g4calo/HcalRawTowerBuilder.cc#L197 and the EMCal: https://github.com/sPHENIX-Collaboration/coresoftware/blob/dd264ae362a1b9f3d60aacd945552bc1258c6ca5/offline/packages/jetbase/TowerJetInput.cc#L497 ).

Regarding the simulation: I do not think that this would be that great of a challenge. There are relatively few places in the simulation code that I can see making use of EpdGeom (specifically here https://github.com/sPHENIX-Collaboration/coresoftware/blob/dd264ae362a1b9f3d60aacd945552bc1258c6ca5/simulation/g4simulation/g4epd/PHG4EPDModuleReco.cc#L82 ) although please correct me if I am wrong.

Aug 15 '25 21:08 largewedge

Build & test report

Report for commit ea6e51026778b9f9c8ffea1adaff0820ddd8db89:

builds and tests overall are FAILURE.
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 FAILURE, :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 = 15.2766 / 72, and combined p-Value = 1
  - :bar_chart: QA-calorimeter for pi+ at p_T=30GeV : combined Chi2/nDoF = 9.83159 / 72, and combined p-Value = 1
  - :bar_chart: QA-calorimetric-jet for e- at p_T=4GeV : combined Chi2/nDoF = -0 / 42, and combined p-Value = 1
  - :bar_chart: QA-calorimetric-jet for pi+ at p_T=30GeV : combined Chi2/nDoF = -0 / 42, and combined p-Value = 1
- Tracking QA with Distortions: build is SUCCESS, :bar_chart: trends
  - :bar_chart: QA-distortions
- Tracking QA at low occupancy: build is FAILURE, :bar_chart: trends
- 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 = 761.732 / 56, and combined p-Value = 1.85197e-124
  - :bar_chart: QA-tracking : combined Chi2/nDoF = 34.8908 / 50, and combined p-Value = 0.948312
  - :bar_chart: QA-vertexing : combined Chi2/nDoF = 504.848 / 112, and combined p-Value = 3.11322e-51
- 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: run the default TrackingProduction/Fun4All_PRDFReconstruction.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

Aug 15 '25 22:08 sphenix-jenkins-ci[bot]

Build & test report

Report for commit 3d4c104db7ceb62f83147a66212a425fe6ff4149:

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 = 15.2766 / 72, and combined p-Value = 1
  - :bar_chart: QA-calorimeter for pi+ at p_T=30GeV : combined Chi2/nDoF = 9.83159 / 72, and combined p-Value = 1
  - :bar_chart: QA-calorimetric-jet for e- at p_T=4GeV : combined Chi2/nDoF = -0 / 42, and combined p-Value = 1
  - :bar_chart: QA-calorimetric-jet for pi+ at p_T=30GeV : combined Chi2/nDoF = -0 / 42, and combined p-Value = 1
- 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 = 680.005 / 56, and combined p-Value = 4.87045e-108
  - :bar_chart: QA-tracking : combined Chi2/nDoF = 66.8732 / 56, and combined p-Value = 0.151585
  - :bar_chart: QA-vertexing : combined Chi2/nDoF = 485.638 / 112, and combined p-Value = 5.53177e-48
- 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 = 753.993 / 56, and combined p-Value = 6.74103e-123
  - :bar_chart: QA-tracking : combined Chi2/nDoF = 34.8908 / 50, and combined p-Value = 0.948312
  - :bar_chart: QA-vertexing : combined Chi2/nDoF = 504.843 / 112, and combined p-Value = 3.1195e-51
- 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: run the default TrackingProduction/Fun4All_PRDFReconstruction.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

Aug 15 '25 23:08 sphenix-jenkins-ci[bot]

The changes to CaloTowerCalib look good to me, even this time saving continue statement, nice! It will take me some time to review the rest of the code though. I don't think we want to make any changes that would effect the event plane in the 2024 auau data until after the Initial Stages push. In the meantime, if there aspects of the calibration code that we want to get into coresoftware (that doesn't effect the core functionality of the EPD), that would be super beneficial use of this time.

Aug 16 '25 18:08 bseidlit

~~Could you clarify a bit about what you mean by the "initial stages" @bseidlit ? I assume that you mean something like an incremental rollout of the changes to sEPD software, where we would make the new code available alongside EpdReco and EpdGeom and would only push changes to the production macros once all of the changes have been pushed. Is that right?~~ Edit: disregard, I realize now that you are talking about the upcoming conference

Also, the converted calibration file that works with CaloTowerCalib is available at /sphenix/user/ecroft/sEPD_condor/calibrations/sEPD_CalibConstants_CDB_Run71504_converted.root. I've tested it with run 71738 and produced a few plots to validate that the N_MIP distributions look like what we expect. Screenshot from 2025-08-18 11-25-06 .

Aug 18 '25 15:08 largewedge

GreatYes, I think we don't want to change the core functionality of the EPD for like 2-3 weeks. Is the code that produces these calibrations on git. If not, you could work on getting that into coresoftware or macros PR'ed and merged b.c. that won't effect the reconstruction but is also necessary.

Aug 19 '25 19:08 bseidlit