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.