faster StripCPE with cached barycenter correction

[slava77]

@elusian @mmasciov

Hi Enrico
I have a commit to test in HLT (it's on my branch slava77:CMSSW_14_2_1/ca-mkf-str-CPE)
The purpose is to speedup hltSiStripRecHits: it's relying on the fact that a fairly expensive computation in StripCPE.cc is actually numerically the same for almost all of the modules.

From the physics point of view it leverages the fact that

• in the barrel where the drift direction is non-trivial, the strip topology is simple and the drift-dependent correction is the same for the full module independent of the local posision
• in the endcaps where strips are non-trivial (trapezoidal topology) the drift direction reduces the correction to 0

This is not bitwise identical. The precision/deviation is hardcoded to be max 0.01 of the strip size (otherwise the standard CPE correction is called). I think this should be good for all.

On 10K events run 386593 (somewhat old menu setup from 14_2_X, used in January for mkFit/CA developments) with mkFit I see 12% speedup in hltSiStripRecHits

[slava77]

My initial "physics level" tests were on MC (checking all calls on 30 events of ttbar relval pileup), where I've seen that the correction is

• within 1e-2 on 14531 (all) modules
• within 1e-4 on 14529 modules
• within 1e-6 on 55

So, a similar speedup would be expected even with 1e-4 tolerance.
I'm not sure how large is the variability in the drift directions in data to be confident to suggest that going to 1e-4 would be fine for timing (this is a more obviously good enough precision).

[elusian]

Hello @slava77 , I did a quick cherry pick of that commit into 15_0_4 and it segfaults inside StripCPE::Param::coveredStrips. I haven't investigated further yet

[slava77]

Hello @slava77 , I did a quick cherry pick of that commit into 15_0_4 and it segfaults inside StripCPE::Param::coveredStrips. I haven't investigated further yet

was it an mkFit in HLT setup or something simpler?

[elusian]

mkFit in HLT, I wanted to compare with the rest of the tests I'm doing in these days

[slava77]

mkFit in HLT, I wanted to compare with the rest of the tests I'm doing in these days

just to be sure, was it tested after a cms-checkdeps?

[elusian]

Yes, that was it, I was used to the git cms-* commands doing that on their own.

This is the impact on HLT tracking on 731 TTbar events and it looks negligible

I wanted to run some timing measurement, but it appears that there is something broken in the timing server, so it's probably going to happen after Easter.

[elusian]

Hello @slava77 , here are the timing measurements:

• Baseline: 481.3 ms, 11 inside SiStripRecHitConverter
• After this commit: 480.6 ms, 8.7 ms inside SiStripRecHitConverter

[slava77]

Hello @slava77 , here are the timing measurements:

* [Baseline](https://cmshlttiming.app.cern.ch/display/elusiani/CMSSW_15_0_4_CA_MkFit.20250419_190742): 481.3 ms, 11 inside `SiStripRecHitConverter`

* [After this commit](https://cmshlttiming.app.cern.ch/display/elusiani/CMSSW_15_0_4_CA_MkFit_StripCPEOpt.20250419_190745): 480.6 ms, 8.7 ms inside `SiStripRecHitConverter`

thanks for the test. I'm guessing the 0.7 ms in the total is a result of down-fluctuation somewhere, otherwise it should be closer to 2 ms.

[slava77]

@elusian
should I make a PR with this commit or can you take care of it?
Please let me know.

[elusian]

I'm about to take the bus so for sure I won't be able today. Tomorrow I can also discuss at the TSG

[slava77]

@elusian should I make a PR with this commit or can you take care of it? Please let me know.

I wanted to check on the status

[slava77]

@elusian should I make a PR with this commit or can you take care of it? Please let me know.

I wanted to check on the status

ping

[elusian]

Hello, apologies for the failed followup.
TSG had requested an higher stat test and I had launched it in crab but it failed and I lost track of it due to other tasks.
In principle the objection was always the same: do we want deep changes now in the middle of the year especially if they include offline?
So we really need to prove that there are no/negligible differences.

[slava77]

In principle the objection was always the same: do we want deep changes now in the middle of the year especially if they include offline?

we are changing a full tracking iteration now (mkFit doublet recovery); perhaps I'm missing the context of either depth ("deep changes") or the date during the year.

The code explicitly checks that changes beyond 0.01 of the strip size are not allowed.
Is there a concern that this is too large? There is room to make this tolerance smaller by a factor of a few.

As for other non-zero changes, we've just accepted one in cms-sw#48351/cms-sw#48318

[slava77]

especially if they include offline?

if necessary, this can be made configurable and disabled offline