import cascase frontend from T2K/ND280/FGD

[dd1]

the software for cascading multiple midas instances was never imported into main midas.

this software permits building a tree of midas instances - the main instance at the root of the tree controls any number of secondary midas instances - with coordinated run control (run start, stop) and event flow from secondary midas to main midas. (provisions exist for sharing parts of odb between the instances).

this is implemented using thwo programs:

• cascade frontend running on the main midas instance - it forwards run transitions & etc to the secondary midas instance and it injects event data from secondary midas back to the main midas.
• the cascade program runs on the secondary midas, it has a tcp socket connection to the cascade frontend in main midas, it receives run transition requests, executes the run transtions and forwards event data from local SYSTEM buffer back to the main midas.

K.O.

[Lukas Berns]

FYI recently we had been using the cascade also to bridge between the 2010~era midas versions and more recent 2022-05-c version. For our particular setup (possibly related to some details of the OS/architectures involved since I couldn’t reproduce this everywhere) we had issues with sending events larger than 1 MB across the cascade, which I couldn’t figure out how to fix. Instead, I wrote a version that uses zeroMQ instead of the custom socket for the event transmission. I assume this is not desired in the sense that it introduces external dependencies, but thought it’s worth a mention.

Furthermore, I am thinking of making some enhancements.

One is about the “transition delay” setting: right now the cascade doesn’t actually wait for the “partition midas” to finish the run start/stop sequence before reporting to the “global midas” that it is ready, but instead waits a fixed number of seconds.

Another is to have some ability to propagate information about alarms across the cascade (either make a new alarm in the global or just change the status).