NeXus is developed as an international standard by scientists and programmers representing major scientific facilities in Europe, Asia, Australia, and North America in order to facilitate greater cooperation in the analysis and visualization of neutron, x-ray, and muon data.

Agenda

Questions below from Dectris (Andreas - Tobias edited for markdown) in preparation of the HDRMX Meeting. For convenience here are links to NXdetector and NXmx.

dead_time, detector_readout_time and frame_time are defined as NX_FLOAT. count_time is defined as NX_NUMBER, all four with units=NX_TIME. Shouldn’t the parameters be of the same data type?

frame_time is described as exposure_time + readout time. To be consistent with the other parameters, this should be count_time + detector_readout_time.

sensor_material is described as “the name of this converter material” for “radiation [..] not directly sensed by the detector”. Can this description be expanded to include directly detected radiation?

Same for sensor_thickness.

flatfield_applied is currently called flatfield_correction_applied. This is arguably in better agreement with angular_calibration_applied. Can we keep it?

Are the group names binding or only their NX classes? For example, EIGER calls the NXcollection group detectorSpecific, not collection. Similarly, the NXdetector_module group is planned to be called module not detector_module.

What does the required parameter /entry/instrument/detector/data[np,i,j] entail?

A parameter like detector_number that gives the serial number should be made mandatory. Or it could be an attribute to /entry/instrument/detector/description?

LCLS HDF5 topics

Next meeting

AOB

Minutes

Present: MK, TSR, AB, AF, HJB, PJ

Website Move

No issues reported, no strong desire to keep user pages. They will be removed and can be reinstated by pull requests from the individuals if they so wish.

Triplicated Minutes

Decision was to keep them in the website repo only. Remaining copies will be deleted.

Dectris Items

times will be changed to the general NX_NUMBER

frame_time clarifcation with the field names actually used is good.

sensor material and thickness: The documentation is both needless specific and vague. The suggestion was to speak of the “active” material.

flatfield renaming: We should check whether that has found active use and only change if not. HDRMX meeting in Lund next week will be used.

group names in application definitions can be made nameless, as in this case. Any name for a group of the right type is acceptable

data is a link to the data

detector_number is already taken for an INT. We propose to define a new string type serial_number.

LCLS HDF5

Aaron had some questions to the use of the new and improved NXlog. There was some discussion around the expected chronological order in there.
There was some agreement that sorting cannot always be guaranteed, but no random ordering should be allowed.

The also have the intention of storing data that could lend itself to using ragged arrays. That is not something perceived to be simple to get right.
Aaron will prepare some example and email that around for comments.