Wednesday, 8th March, 16:30 Central European Summer Time (Copenhagen)
Hangout Link: https://plus.google.com/hangouts/_/j72qwlvegiojjpt3a36pfhow5ua
frame_timeare defined as
count_timeis defined as
NX_NUMBER, all four with units=
NX_TIME. Shouldn’t the parameters be of the same data type?
frame_timeis described as
exposure_time + readout time. To be consistent with the other parameters, this should be
count_time + detector_readout_time.
sensor_materialis 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?
flatfield_appliedis currently called
flatfield_correction_applied. This is arguably in better agreement with
angular_calibration_applied. Can we keep it?
collection. Similarly, the
NXdetector_modulegroup is planned to be called
detector_numberthat gives the serial number should be made mandatory. Or it could be an attribute to
Present: MK, TSR, AB, AF, HJB, PJ
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.
Decision was to keep them in the website repo only. Remaining copies will be deleted.
detector_numberis already taken for an
INT. We propose to define a new string type
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.