`filewriter`: `runlog/icp_event`

Bắt đầu bằng cách lần theo cách filewriter tiêu thụ luồng dữ liệu sự kiện nền tảng và cách nó hiện ghi các nhóm runlog. So sánh các lệnh newStyle được đề xuất với hành vi phân tích cú pháp mà Mantid nêu ra, sau đó xác minh rằng START_COLLECTION, STOP_COLLECTION, CHANGE và CHANGE_PERIOD phản ánh các chuyển tiếp frame và period tốt/xấu; xác định liệu ABORT có thuộc phạm vi cần xem xét trước khi coi công việc là hoàn tất hay không.

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.