Regression in tracking in the B0 with newer version of epic

[ajentsch]

As the first samples from the 25.10.1 exclusive (DVCS, in particular, for the example here) physics campaign came out, an issue was noted in the acceptance of the B0 tracker.

Using files from 25.06.1 (they were on-hand), the following acceptance is noted for the B0:

The B0 is the portion in the dark blue.

This is the result from the 25.10.1 files:

Focusing on the dark blue curve, the B0 angular acceptance has been reduced significantly, with a cutoff almost 1.5 mrad higher in theta than before.

Looking at samples from 25.08.0 (left) and 25.10.1 (right), the hit distribution look as the are expected to look:

The only geometry change is seen on the left side of these plots, and that would only affect very high-angles in the B0, not the ones at the lower end, and certainly not to the degree we are seeing.

Using small samples from 25.08.0 (left) and 25.10.1 (right), we also see the number of reconstructed tracks is significantly reduced, for the same MC events:

The conclusion is that some changes in ACTS have affected the B0 tracking and resulted in fewer reconstructed tracks.

[ajentsch]

B0behaviour_4Nov25.pdf

The problem started in July. The geometry/hits are okay from month to month, it's the tracking itself that seems problematic. Thanks to Oliver for making the comparison plots.

[veprbl]

So the conclusion is that we see the regression starting from 25.07.0, but there was no change to Acts in https://chat.epic-eic.org/main/pl/jtjpqbimyjf95boaz8fst6od5y. That was the release with the new beamline geometry, it might be interesting to try to revert that and see.

It might be useful to post the script here.

[ajentsch]

Hey guys,

Here are file paths to necessary "analysis" scripts, etc.

Analysis script + header: /gpfs02/eic/ajentsch/ePIC_dd4hep_simulations/analysis/dvcsAnalysis/analyze_DVCS_eicrecon.C /gpfs02/eic/ajentsch/ePIC_dd4hep_simulations/analysis/dvcsAnalysis/detectorResolution.h

(better to run with "root -b", or to comment out the lines where the detector resolutions are calculated: L512 to L552)

And a tiny script to generate a file list: /gpfs02/eic/ajentsch/ePIC_dd4hep_simulations/analysis/dvcsAnalysis/generateFileList.C

Here is the filepath to an input hepmc files for testing (already afterburned, etc.):

/gpfs02/eic/ajentsch/ePIC_dd4hep_simulations/mcData/dvcsFilesFromEpIC/dvcs_10x100_ABCONV.hepmc

Additionally, here are the npsim and eicrecon commands, for convenience (modify to get needed number of events):

npsim --inputFile /gpfs/mnt/gpfs02/eic/ajentsch/ePIC_dd4hep_simulations/mcData/dvcsFilesFromEpIC/dvcs_10x100_ABCONV.hepmc --outputFile [your_folder_here]/simulationOutput/npsimOutput_10x100_DVCS_[number].edm4hep.root --compactFile ${DETECTOR_PATH}/epic_craterlake_10x100.xml -N [num_events] --skipNEvents [skippy_skip]

eicrecon -Ppodio:output_file=[your_folder_here]/reconstructionOutput/reco_DVCS_10x100_polynomial_testing_10_10_2025_${1}.eicrecon.root [your_folder_here]/simulationOutput/npsimOutput_10x100_DVCS_[number].edm4hep.root -Pdd4hep:xml_files=${DETECTOR_PATH}/epic_craterlake_10x100.xml

[veprbl]

This is a regression from d1be407230b6ee8cb02aaf700ee6442e4aea59de on the reconstruction side.

The Acts surfaces shrink. Previous commit (7e72bb5fa97870fb51a61e7c0e0a5e47dacd4118):

This commit (d1be407230b6ee8cb02aaf700ee6442e4aea59de):

Specifically, changes to compact/far_forward/B0_tracker.xml (https://github.com/eic/epic/commit/d1be407230b6ee8cb02aaf700ee6442e4aea59de#diff-4a3018980fe91737f1e6416c17872d333e6f8b1329b591eac40b87dcfb25878e) are introducing the issue.

[veprbl]

(Moved from EICrecon to epic)

[ajentsch]

@veprbl I do not understand this. The adjustment to the geometry was only on the tiny section of the tracker which is between the beam pipes. That would only affect the acceptance in a tiny region of the detector, and at higher pT, not the region we see the loss. How does this change affect the tracking acceptance but in the wrong region of pT?

[veprbl]

I only have a guess here. It should be that the lines we see on the plot must correspond to disks, which have rmin bounds, so the center of such disk must be shifting and the position of the cutout must be shifting.

[ajentsch]

Hmm, this is different from what @wdconinc showed me. I thought the issue was that the outer radius of the larger B0 tracker disks created an ACTS surface which intersected the z_axis (electron line). It seemed the slightly shrinking the outer radius if the big disk by a few mm could solve the problem.

[veprbl]

Using @wdconinc's September patches, together with #1009 the performance is better than it used to be The new approach surfaces are approximating the sensitive layers quite well now:

I hope, B0 group can perform full evaluation of the expected acceptance.