Telco 20170308¶
Date¶
Wednesday, 8th March, 16:30 Central European Summer Time (Copenhagen)
Hangout Link: https://plus.google.com/hangouts/_/j72qwlvegiojjpt3a36pfhow5ua
Agenda¶
Welcome and agree Agenda
wiki & website move
any outstanding problems
return of user pages?
Github NIAC repo & minutes in communication
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
andframe_time
are defined asNX_FLOAT
.count_time
is defined asNX_NUMBER
, all four with units=NX_TIME
. Shouldn’t the parameters be of the same data type?frame_time
is described asexposure_time + readout time
. To be consistent with the other parameters, this should becount_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 calledflatfield_correction_applied
. This is arguably in better agreement withangular_calibration_applied
. Can we keep it?Are the group names binding or only their NX classes? For example, EIGER calls the
NXcollection
groupdetectorSpecific
, notcollection
. Similarly, theNXdetector_module
group is planned to be calledmodule
notdetector_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 anINT
. We propose to define a new string typeserial_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.