Phase2 duplicate pixels handling

[jpata]

In #37559 (comment) it was noticed that duplicate pixels are not treated correctly in the Phase2 pixel digitizer. As I understand, their appearance is currently related to the simulation code.

In the longer term (as I suggested above) - certainly longer than the target of this PR (~ urgent for Run3 consistency ), I think the digitizer logic should be changed to avoid duplicate simDigis and just sum them up upstream of any recontruction.

In the meanwhile this can become an open cmssw issue with simulation signature

[jpata]

assign simulation

[cmsbuild]

New categories assigned: simulation

@mdhildreth,@civanch you have been requested to review this Pull request/Issue and eventually sign? Thanks

[cmsbuild]

A new Issue was created by @jpata Joosep Pata.

@Dr15Jones, @perrotta, @dpiparo, @rappoccio, @makortel, @smuzaffar, @qliphy can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[mmusich]

assign trk-dpg

[mmusich]

@emiglior @suchandradutta FYI

[cmsbuild]

New categories assigned: trk-dpg

@connorpa,@mmusich,@tsusa you have been requested to review this Pull request/Issue and eventually sign? Thanks

[mmusich]

urgent

• apparently PR Remove duplicate pixels #37559 has created a serious deterioration of the phase-2 track reconstruction (see https://cms-talk.web.cern.ch/t/new-validation-campaign-12-5-0-pre5-phase2-d88-added/14722/15)

[srimanob]

FYI @cms-sw/l1-l2
How do you use RECO track in L1T campaign? Could you please see the report above on degradation of tracks?

[srimanob]

Hi @mmusich

Thanks for pinging me.
Should I assume the issue of tracks will propagate to objects, like electron, muon, jet right? Maybe we need to see how the issue will effect globally also.