`filewriter`: `runlog/icp_event`

Inizia tracciando il modo in cui il filewriter consuma il flusso di dati degli eventi sottostante e il modo in cui attualmente scrive i gruppi di runlog. Confronta i comandi newStyle proposti con il comportamento di parsing dichiarato da Mantid, quindi verifica che START_COLLECTION, STOP_COLLECTION, CHANGE e CHANGE_PERIOD riflettano transizioni di frame e di periodo buone/cattive; stabilisci se ABORT debba essere incluso prima di considerare concluso il lavoro.

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.