`filewriter`: `runlog/icp_event`

[Tom-Willemsen]

The filewriter must be able to write the runlog/icp_event group, as parts of this are currently parsed by Mantid.

From discussions, my current understanding is that Mantid:

• Does read CHANGE_PERIOD and CHANGE events. We will emulate these by looking at the event data stream and emitting a fake CHANGE_PERIOD message each time we see incoming data with a different period number.
• Does read START_COLLECTION, STOP_COLLECTION, ABORT messages.
• Can read BEGIN, RESUME, END_SE_WAIT, PAUSE, END, ABORT, UPDATE, START_SE_WAIT messages, but only if oldStyle is being used.
• Does not parse the numbers from GF x RF x GUAH x messages.

Potential differences from existing files

• Proposal is to only write the newStyle commands, so START_COLLECTION, STOP_COLLECTION, CHANGE, CHANGE_PERIOD, ABORT.
• All data will be emulated (derived from the underlying event data):
  • START_COLLECTION written at the beginning, and then on any transition from a bad frame to a good frame.
  • STOP_COLLECTION written on any transition from a good frame to a bad frame, and then at the end.
  • ABORT - not convinced this is meaningful, if the run is aborted then won't get a .nxs file at all...
  • CHANGE_PERIOD will be written any time we get a frame which has a different period than the most-recently-seen frame
• CHANGE_PERIOD will account for hardware periods as well as software periods (they look the same to the filewriter in the streaming system). This means that there could be a much higher frequency of CHANGE_PERIOD events than previously.
• START_COLLECTION and STOP_COLLECTION will account for hardware vetos as well as pause/runcontrol (they look the same to the filewriter in the streaming system). This means that there could be a much higher frequency of START_COLLECTION and STOP_COLLECTION events than previously.

[Tom-Willemsen]

Tris has confirmed that GudRun does not use runlog/icp_event.

[martyngigg]

What what Mantid does with the icp_event (it actually checks for both this and icpevent names). It has a hardcoded set of commands that it interprets:

 if (newStyle) {
 command_map["START_COLLECTION"] = commands::BEGIN;
 command_map["STOP_COLLECTION"] = commands::END;
 command_map["CHANGE"] = commands::CHANGE_PERIOD;
 command_map["CHANGE_PERIOD"] = commands::CHANGE_PERIOD;
 command_map["ABORT"] = commands::ABORT;
 } else {
 command_map["BEGIN"] = commands::BEGIN;
 command_map["RESUME"] = commands::BEGIN;
 command_map["END_SE_WAIT"] = commands::BEGIN;
 command_map["PAUSE"] = commands::END;
 command_map["END"] = commands::END;
 command_map["ABORT"] = commands::ABORT;
 command_map["UPDATE"] = commands::END;
 command_map["START_SE_WAIT"] = commands::END;
 command_map["CHANGE"] = commands::CHANGE_PERIOD;
 command_map["CHANGE_PERIOD"] = commands::CHANGE_PERIOD;
 }

It then builds two separate time-series logs that it adds to the workspace:

• A boolean value log where true marks the timestamp of when BEGIN was last called and false marks the timestamp of when END was last called.
• An integer value log where each time CHANGE_PERIOD n is encountered it appends a (timestamp, n) pair to define the period number at that time.

There seems to be no parsing of numbers in GF x RF x GUAH x nor anything related to any other commands than those listed above.

[Tom-Willemsen]

Thanks @martyngigg .

Did you have any thoughts on:

• CHANGE_PERIOD will account for hardware periods as well as software periods (they look the same to the filewriter in the streaming system). This means that there could be a much higher frequency of CHANGE_PERIOD events than previously.
• START_COLLECTION and STOP_COLLECTION will account for hardware vetos as well as pause/runcontrol (they look the same to the filewriter in the streaming system). This means that there could be a much higher frequency of START_COLLECTION and STOP_COLLECTION events than previously.

Do you have a feeling for whether a high frequency of START_COLLECTION and STOP_COLLECTION events would cause performance or other problems in Mantid? For example:

• On a TS1 instrument you may get the TS2 pulse veto coming on and off at 10Hz continuously.
• On an instrument using hardware periods, we will likely implement dwell periods as a veto, this could in principle cause a 'bounce' every other frame for a DAQ/DWELL/DAQ/DWELL sequence

Similarly for hardware periods, as hardware/software periods look the same to the streaming system, you may now see a lot more period changes than previously as you'll also see the hardware-triggered ones which may change once-per-frame repeatedly - so in theory could get updates at 50Hz.

We can add extra logic to 'debounce' / filter out these high-frequency runstate transitions if we need to... at the cost of increasing complexity the more of this 'special' logic we need to add.