Fixed invalid reference bug when # of tracks exceeds 32767

[istaslis]

The invalid reference bug was fixed using integer instead of short type for keys in track collection. Number of tracks can exceed 32767.

[cmsbuild]

A new Pull Request was created by @istaslis (Stas Lisniak) for CMSSW_7_5_X.

Fixed invalid reference bug when # of tracks exceeds 32767

It involves the following packages:

RecoTracker/FinalTrackSelectors

@cmsbuild, @cvuosalo, @slava77 can you please review it and eventually sign? Thanks.
@ghellwig, @makortel, @GiacomoSguazzoni, @rovere, @VinInn, @mschrode, @gpetruc, @cerati, @dgulhan this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
If you are a L2 or a release manager you can ask for tests by saying 'please test' in the first line of a comment.
@Degano you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[slava77]

If this bug was reported somewhere, please provide a reference.
I'm curious to see an example of an event with more than 32767 tracks.

[slava77]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.

[istaslis]

Please, look at the event 9719724 in the file below

https://cmsweb.cern.ch/das/request?view=list&limit=50&instance=prod%2Fglobal&input=file+dataset%3D%2FHIMinBiasUPC%2FHIRun2011-v1%2FRAW+run%3D182124+lumi%3D221

[slava77]

@istaslis
Your DAS link points to a RAW file.
Some reconstruction is needed. Which release was used to see so many tracks?
(was this error reported in some relval?)

One place where I can imagine more issues downstream is the PF reconstruction: PFCandidates pack track refs as unsigned shorts.

How many tracks did we have in the event in question?

[istaslis]

@slava77
This error was reported during relval of CMSSW_7_5_0 (workflow 140.53) on track reconstruction (in the hiGeneralTracks module). Because of many tracks during HI tracking, oldKey becomes negative and InvalidReference exception fires.

[slava77]

Can we change to uint32_t instead?
I wanted to avoid that potential problem in PF packing

[istaslis]

It works fine with uint32_t. Do you want me to make new PRs?

[slava77]

Nice
Just push your commit to the same branch. The PR will update automatically
On Jul 27, 2015 8:50 AM, "Stas Lisniak" notifications@github.com wrote:

It works fine with uint32_t. Do you want me to make new PRs?

—
Reply to this email directly or view it on GitHub
#10379 (comment).

[istaslis]

Done!

[slava77]

with some more thought, the relationship to PFCandidate packing is not very relevant.
uint32_t is still a more correct choice than a signed int

[slava77]

+1

for #10379 15206dd

• the same code as in the 76X version of the PR (Fixed invalid reference bug when # of tracks exceeds 32767 #10380 f9f4f1b)
• since the jenkins tests didn't complete here, signoff is based on observations with the 76X version

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_5_X IBs once checked with relvals in the development release cycle of CMSSW (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar

[davidlange6]

+1