Monitoring task for detector correlations

This is a new monitoring task that aims for monitoring basic level quantities - in this case detector correlations - that do not rely on the full tracking and reco... - in the ideal case only needs detector decoding.

The task gives shows independent correlations for

• Beam-Empty bx's
• Beam-Beam bx's And duplicated with large ranges (targeting PbPb) and small ranges (targeting pp)

Below for a pp run (308358) the VELO-UT correlation in fine and coarse and bb and be

changed milestone to %RTA 2025 Data taking

added Monitoring label

requested review from @rmatev, @cagapopo, and @msaur

assigned to @tmombach and @pkopciew

added RTA label

added 1 commit

• 3a3ceba4 - Fixed formatting

Compare with previous version

mentioned in issue #90

@rmatev @cagapopo please have a look. This is the task that @collinsp had requested. It's not as fast as I would have wished it to be (3.5k pp events in 2 min), but a significant speedup. Maybe you have an idea how to speed up further?

Hi Titus,

Do you have a picture of how the new pages will look? (the one with small range axes, the one with large range axes)? Also are the plots made for all beam crossing types? Maybe the slowness is the mixture of events coming to the monitoring? Are you filtering on the new nobias line? Thanks!

I put some more explanation in the description. The axis range adaptation for the small and the large ranges is done in the MR Rec!4309 Plots with these included coming up. I am currently checking about the speed. It seems like filtering on the Lumi RB vs not filtering on the Lumi RB indeed cuts the rate by x3, so that suggests like the task is at the limit of events that it receives. But to be confirmed.

On the "new nobias line" if I remember correctly this was something independent of hlt1 lines, so it's something that is indeed automatically being taken into account.

ok, I correct: in a local test with the test bench I see that I have 40% more events on pp when running without filtering on the lumi routing bit vs not filtering on anything (other than beam-beam and beam-empty)

(seeing the ranges for the UT I extended them still to 4.5k, now not cut off anymore, PbPb was fine)

added 4 commits

• ad5d701b - Manual reference update for Gaudi v39r4
• 50baeeba - Update References for: Allen!1789 (merged) based on lhcb-master-mr/13119
• 63f72fba - Update References for: Allen!1502 (merged), Moore!4642 (merged) based on lhcb-master-mr/13145
• 412ace54 - Add correlmon.qmt test

Compare with previous version

I added correlmon.qmt test for the CorrelMon job.

added 9 commits

• 412ace54...83b210d6 - 6 commits from branch master
• ef48ad84 - monitoring task for detector correlations
• d1bde78a - Fixed formatting
• 1c7ffe48 - Add correlmon.qmt test

Compare with previous version

added 5 commits

• 1c7ffe48...4ffc794a - 2 commits from branch master
• fea592ca - monitoring task for detector correlations
• c7a78456 - Fixed formatting
• ae887999 - Add correlmon.qmt test

Compare with previous version

Hi @dmendoza, this MR is ready for testing

/ci-test

Started integration test build. Once done, check the results or the comparison to a reference build.

Throughput Test MooreOnline_hlt2_pp_2024_data: 169.4 Events/s -- change of -0.06% vs. reference

In the current form everything looks good!

great, looks ready to go! Passing this to @msaur

I added the lumi routing bit, so maybe this can benefit another test (although I did run the test locally and it works). Sorry for the extra one. Otherwise, I think this is good to go.

added ci-test-triggered label

• [2025-04-04 13:54] Validation started with lhcb-master-mr#13224
• [2025-04-07 11:36] Validation started with lhcb-master-mr#13253

changed the description

changed the description

added 4 commits

• 9874f9eb - monitoring task for detector correlations
• 3a3ceba4 - Fixed formatting
• 240761bf - Merge branch 'tm_correlmon' of https://gitlab.cern.ch/lhcb/MooreOnline into tm_correlmon
• 87872f96 - add lumi routing bit

Compare with previous version