Consistent output from McStas and file-writer.

[YooSunYoung]

[WIP] McStas team requested for specifications of what we need from the McStas output. Ultimately would like them to be consistent with the file-writer. So here we will collect the difference between the current output of the McStas and the file writer.

Files

/ess/data/coda/2024/616254/raw/616254_00011777.hdf this file is the NMX file that file-writer wrote... (Please someone let me know if there is an easy way to figure out which instrument they are for...!)

Event Data

Event data as a group of dataset instead of a matrix

For example, NMX event data from bank01_events_dat_list_p_x_y_n_id_t has 6 columns and each column corresponds to the p, x, y, n, id, t. It'll be nice if they are separate datasets under the instrument/detector_panel_0/event_data, with corresponding dtype/units/class and description in the attributes. Such as

• instrument/detector_panel_0/event_data/p
• instrument/detector_panel_0/event_data/x
• ...

Event data as event data.

p in the event data is not really a pixel hit as we would expect from a real detector. It'll be great if we can set a threshold on p that can be translated this p into real event data, f.x. if

p  = [0.1, 0.2,  0.1,   0.3,  0.2  ]
id = [1,    2,      3,     4,     5     ]
t   = [0.1, 0.11, 0.12, 0.13, 0.14]

and then we set up a threshold of 0.15, and turn this into event data

event_id                 = [2,      4,      5    ]
event_time_offset = [0.11, 0.13, 0.14]  # second, fourth, fifth

(Maybe it doesn't make any sense after all... I don't know how exactly p works...)

Event data should be under a corresponding detector under the instrument.

It will allow us to find the corresponding event data of each detector/monitor more easily.

f.x.

bank01_events_dat_list_p_x_y_n_id_t should be under

instrument/detector_panel_0/

Geometry

• Geometry information of each instrument/monitor should be in the same place as the event data. It will allow us to find the corresponding geometric information of each panel more easily. f.x.

It will be easier for us if the pixel offsets are saved per pixel IDs, but if it's not feasible, just splitting geometry information into corresponding instrument/monitor data will be already great.

Missing Information

• Reference Time (event_time_zero)
• Flux of proton (neutron) We need a flux of the proton/neutron (NMX uses proton flux for some reason) for normalization steps. And it'll be easier
• Integer Counts It'll be nice if we can set a threshold of the pixel hit and turn them into 1 or 0 and drop all 0s.

[YooSunYoung]

We had a meeting with McStas team on 27/6/24 (Thu).

Here are some notes from the meeting:

• Rotation is relative to the positional vector of the component.
• All transformation is on the global coordinate, not to the previous component.
• Prototype version saves the centre position of each pixel.
• How to decide the axis is to be further investigated.
• We(Data reduction side) would prefer to have all positional offsets so that we don't have to apply transformation at all.
  • scippneutron uses depends_on to calculate the actual position but if we already have actual position in the global coordinate, we can just not have any depends_on.