FEDid-wheel mapping fixed for +1 and +2

[jpazzini]

swapped the FED-wheel_numbers to get the correct mapping for wheels +1 and +2

[cmsbuild]

A new Pull Request was created by @jpazzini for CMSSW_8_1_X.

It involves the following packages:

EventFilter/L1TXRawToDigi

@cmsbuild, @davidlange6 can you please review it and eventually sign? Thanks.
@Martin-Grunewald this is something you requested to watch as well.
@slava77, @Degano, @smuzaffar you are the release manager for this.

cms-bot commands are list here #13028

[fcavallo]

We would like this PR to be included URGENTLY! ideally before the start of MWGR#4. We can patch the Prompt Offline Analysis but not the DQM and with the TwinMux map messed up data are crazy as well!

[jpazzini]

a backport to 8_0 has been created for this PR:

#13772

please consider this for an urgent approval (needed for MWGR#4)

[davidlange6]

please test

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/11964/console

[cmsbuild]

+1
Tested at: 99bf145
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-13742/11964/summary.html

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-13742/11964/summary.html

[davidlange6]

I don't think having this electronics map hardwired in the code is a good long term solution. Is there not a way to derive it from the DetId or other information inside the FED payload itself?

[fcavallo]

We will search for a better, more elegant, final solution.
Meanwhile, please consider:

• This map is a plain set of 5 pairs of numbers (FED, wheel) and is not hard-wired in the code but rather in a configuration file.
• The map itself is not something that is expected to change very often in the future (the present change is just a bug fix).
• At the moment the shifter is forced to run on RAW data in order to apply the fix "manually".