LumiBlockComps: Fix handling of invalid per-BCID lumi data.

There were a number of issues in the handling of invalid per-BCID lumi data in LuminosityCondAlg.

If we see that the per-BCID luminosity is invalid in LuminosityCondAlg::updateMuToLumi, then we should give up on trying to unpack the per-BCID data further. This matches what LuminosityTool was doing.

However, the test for whether the per-BCID lumi is valid was copied from LuminosityTool as:

  int perBcidValid = (m_Valid/10) % 10;

Keep in mind that for Run 1, m_Valid>>22 is also the preferred channel number; doing both this and extracting the 10's digit is kind of strange (think about how you would have to pack that in the first place). And indeed, if one looks in https://twiki.cern.ch/twiki/bin/view/AtlasComputing/CoolOnlineData?redirectedfrom=Atlas.CoolOnlineData, it appears that the code that was in LuminosityTool was actually wrong --- you're supposed to do

  int perBcidValid = ((m_Valid & 0x3ff) /10) % 10;

which does seem more sensible. So fix the validity tests like this.

However, we then run into a further problem. In some data from run 1, the validity word was 884998144 = 0x34c00000, which is (211 << 22). So this would have been rejected by the buggy validity test but not by the fixed one. However, in this example, BunchLumis does not in fact contain the channal 211 (only 102 and 201; 211 is in OnlineLumiCalibration). This was leading to a crash --- so add further protection against this.

See ATLASRECTS-5001.

This merge request affects 1 package:

• LumiBlock/LumiBlockComps

added DQ master review-pending-level-1 labels

enabled an automatic merge when the pipeline for cf7a59f7 succeeds

CI Result SUCCESS

	Athena	AthSimulation
externals
cmake
make
required tests
optional tests

Full details available at NICOS MR-24223-2019-06-16-01-13
Athena: number of compilation errors 0, warnings 0
AthSimulation: number of compilation errors 0, warnings 1
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 382]

merged

mentioned in commit c3d5b185

added sweep:ignore label

Hi Scott,

I believe you have found an old bug and I agree with your fix. The issue was always the mixing of decimal places to store information and the channel number as a bit shift. This is indeed correct: int perBcidValid = ((m_Valid & 0x3ff) /10) % 10;

Note that this was only a problem in Run 1 data, as we added a payload to hold the preferred channel ID for Run2, so the packing into the validity word wasn't used after 2012.

By the way, I don't seem to be getting these messages (Peter Onyisi sent me this one directly). How do I get added to the list for messages about this package?

Regards, Eric