Do we need to invent the concepts of a SpillId and MICycleId

[kutschke]

There have been discussions about organizing ExtMon and STM data by DR Spill and/or MI cycle ( 4 or 8 spills for 1BB or 2BB). Do we need to invent the concepts of a SpiilID and MICycleID to label such data and correlate it with information from the other subsystems? A SpillID might also support studies of proton bunch intensity fluctuations within a spill. A MICycleID might support the organization of the STM measurements of the long lived Mg line.

The following is a strawman proposal for how to implement such IDs. It presumes that subruns will contain an integer number of MI cycles. The proposal is that MICycleID has two fields,

1. art::SubRunID
2. MI Cycle number, restart at 0 at the start of a subrun

And a SpillID has 2 fields

1. MCCycleID
2. Spill number, restart at 0 at the start of a MICycle

I propose to implement these ID's following the model of art::EventID and resusing art::SubRunID for the first field.

We will need to discuss with the TDAQ group how to pass the required information from the DAQ system to the software that will create these IDs.

Who are the stakeholders in this? I think:

1. Offline computing
2. TDAQ
3. Analysis groups that will use data labelled with these IDs.
4. Others?

[rlcee]

Instinctively, I think this is a really good idea. My only comment would be that maybe in some cases it would help to not tie them to subruns, but make them a continuous global counter, like eventwindowmarkers. If you think of it as dividing the calibration into smaller bits, then resetting makes sense, but if you are analyzing a stream of STM data over days, the global counter might be easier to work with. I don't recall a decision on how the "STM running past the end of beam" will be handled, or if the STM will even have the same run number as the big detector, and those decisions might be relevant.