In part as a follow up to the investigations in the final fit by Mario that so far converged on disabling probQ computation https://github.com/cms-sw/cmssw/pull/39776, it may be good to see if more flexibility can be added in the pixel CPE, to deliver generic where it reasonably works and in other parts to use, the template reco.
A single ES product may be a better solution, rather than having the client code switch a value.
If the fraction of calls to template is relatively small, this flexible CPE could be used in HLT for full track fits.
The design of flexibility could be driven by knowledge of differences between generic and template based residuals.
Is somebody in the pixel group available/interested to implement this? We could test different options on the tracking side.
In part as a follow up to the investigations in the final fit by Mario that so far converged on disabling
probQcomputation https://github.com/cms-sw/cmssw/pull/39776, it may be good to see if more flexibility can be added in the pixel CPE, to deliver generic where it reasonably works and in other parts to use, the template reco.A single ES product may be a better solution, rather than having the client code switch a value. If the fraction of calls to template is relatively small, this flexible CPE could be used in HLT for full track fits.
The design of flexibility could be driven by knowledge of differences between generic and template based residuals. Is somebody in the pixel group available/interested to implement this? We could test different options on the tracking side.
cc @slava77 @mmasciov