Add reading and return to client of event monitor data in SNSLiveEventDataListener

[Russell Taylor]

This will be parsing the packets and adding the events to the monitor workspace held within the main workspace (which will be added in #9541).

It will need to include creation of this workspace with the correct number of spectra, including doing so after extractData has been called and dealing with run transitions (all in the same way as the 'main' workspace handles things).

[Russell Taylor]

Re #9542. Create a monitor workspace.

The monitor workspace is created in the initialization step at the same time as the 'main' workspace. It is embedded inside the data buffer workspace using the new functionality for that (setMonitorWorkspace). It shares the instrument etc. with this main workspace and has the detector IDs wired up properly.

On each call to extractData() a fresh, empty copy of this monitor workspace is created and placed within the similarly fresh data buffer workspace.

Changeset: 4b5f7a342f1083edbcf455c78ce23b09809c58f7

[Russell Taylor]

Re #9542. Populate the monitor workspace with events.

The code to parse the packets was already there, so this step is easy. For each event we just find the right event list and pop it in.

Changeset: 3d6e5cc50f1b4ad52268583d53dfe38ac6b8c122

[Russell Taylor]

Re #9542. Indentation fix only.

Changeset: d23d20b12ba1404fe6da8667cac97ca60c2a4328

[Russell Taylor]

Re #9542. Avoid logger stream methods where possible.

They are much less performant. Of course, this only really matters if the line is called often, but I am trying to be consistent.

Changeset: 2d82df8236c6cbeae4a7888e1797c4840cfecda2

[Russell Taylor]

Re #9542. Log error if an event from an unknown monitor is seen.

Changeset: 1959e5c6dd9aa1480c96fd784356901de4eb31bf

[Russell Taylor]

To test, you will need access to the live stream of an SNS instrument or to be called Ross and have your own test harness.

Start up live data session. Because the adding of monitor data has not been put into the general infrastructure yet (see #9543), in order to see the monitor workspace in the final output workspace you will need to set "Update Every" to 0 to stop after one call to LoadLiveData. Then you can run ExtractMonitorWorkspace on the output workspace to fetch the monitors. You can then compare the number of events to those in the "monitorN_counts" sample logs - they should be very similar though may not be exactly the same (checks seem to show that it's the logs that are not quite right).

You could also try calling ExtractMonitorWorkspace in the processing step to examine things there. Use a script something like this:

mon = ExtractMonitorWorkspace(ws)
numlists = mon.getNumberHistograms()
for i in range(0,numlists):
    print mon.getEventList(i).getNumberEvents()

[Ross Miller]

Merge remote-tracking branch 'origin/feature/9542_monitor_events_in_sns_live_listener'

Full changeset: ​64270d8ba38575f2b48bfe082b45358ea54d421d

[Ross Miller]

Tested using CORELLI and HYSPEC data. Everything looks good and there were no discrepancies in the the monitor event counts. I had to use the 'preserve events' option in StartLiveListener in order for the monitor workspaces to show up at all, but Russell says that should be handled in #9543.

[Russell Taylor]

On reflection, I'm not going to 'fix' the issue described above and it prompts me to comment on the implications of the chosen design....

Running any algorithm on a workspace that holds a monitor workspace will discard the monitor workspace (unless input and output are the same workspace). That's what's happening when 'preserve events' is no checked (ConvertToMatrixWorkspace is run). I will be manually circumventing that in LoadLiveData at the point it calls Plus to accumulate chunks. There's no point in doing so for the ConvertToMatrixWorkspace call because in order to get anything useful out of that, you have to do some processing (at minimum a Rebin) in order to get something useful out - and that would drop the monitor workspace.

So the situation is this: You only can only successfully call ExtractMonitorWorkspace on the final output workspace if there are no processing or post-processing algorithms run. If the processing step is empty, then the monitor events will be accumulated and be available to the post-processing step. It is up to the user who cares about monitor data to get hold of the monitor workspace at the appropriate point to avoid it being lost.

[Stuart Campbell]

This ticket has been transferred to github issue ​10385