BeamSpotMonitor can track IR conditions produced by third parties

Related Issues and MRs

Part of a set with Moore!5265 (merged) and MooreOnline!661 (merged).

Related to !4536 (merged), but not dependent on it.

Description

Adds functionality to BeamSpotMonitor that allows it to update its internal cache to follow new InteractionRegion conditions produced by other processes. This functionality is modal and steered by a new property IRCondInitStrategy, which controls both how BeamSpotMonitor initializes its internal cache and where it looks for third-party updates.

The internal cache of conditions are used to evaluate the publication criteria. If there is an independent process that can write new InteractionRegion conditions, then these cached values must be updated before making a decision about whether or not to publish an update.

New Property

The new property IRCondInitStrategy has the following options:

• 'Autonomous': BeamSpotMonitor never checks for third-party updates. It keeps track of the conditions that it has published since initialization and updates its cache based on what it has most recently published.
• 'FromDBFile': At initialization, BeamSpotMonitor reads the YAML file with the largest version number into its cache. When the accumulator reset conditions are met (either when a suffiently large sample has been accumulated or at a run change), the cache is updated from the YAML file with the largest version number at this later time.
• 'FromCond': At the first event, BeamSpotMonitor initializes its cache from the run-time conditions. When the accumulator reset conditions are met (either when a suffiently large sample has been accumulated or at a run change), the cache is updated from the current run-time conditions.

Testing

I ran private tests with the online testbench for each of the modes to check that the behavior matched what was intended. The dataset for my tests consisted of two MDF files from different runs:

1. Run 325825

• Collected on 2025-07-17
• Corresponds to InteractionRegion v475

2. Run 328702

• Collected on 2025-08-29
• Corresponds to InteractionRegion v584

The BeamSpotMonitor update thresholds were set so that it would produce several conditions updates when running over these datasets.

Autonomous mode

The code for initiazing the internal cache from a file or from the run-time conditions provider is never called. Published updates are consistent with the BeamSpotMonitor algorithm's internal tracking of the conditions that it published.

FromCond mode

In this mode, i should see the code that updates the interal cache from the run-time conditions provider called at initialization, at the run change in the data, and each time that the configured number of PVs has been accumulated. The initialized values should be identical to either InteractionRegion conditions v475 or v584 depending on the run being processed.

And this is what i do see. This mode works as intended.

FromDBFile mode

This is the trickiest mode to test. A new conditions file needs to be added to the local database while the BeamSpotMon task is running in the testbench. It is not that hard to do manually, just took a bit of timing.

Because the task is running with a local output database that is created in the initialization phase of the BeamSpotMonitor algorithm, i should see a warning in the logfile indicating that there is no initial DB file from which to initialize the algorithms cache. (This is not an issue when running online because it uses the online conditions database rather than creating a new local database.) Then, i should see the task publish conditions updates normally starting at v0. My manually copied conditions had filename v3456, so i should see the BeamSpotMonitor read these conditions into its cache and then proceed publishing updates from v3457.

And this is what i do see! This mode works as intended.