Wednesday, 17th June, 12:00 BST
Hangout Link: https://plus.google.com/hangouts/_/g2e2ayoq57srpi2g4zv2c2ewbua
Fluo : NXdetector
@signal = data
@axes = (,,,energy)
@energy_indices = (3)
@interpretation = spectrum
@units = keV
Present: MK, MB, EW, HJB, TSR, AF (Dectris, from holiday!)
NXmx, fill values
This started from an Dectris Eiger problem of having to write fields without knowing values. Those are them meant to be filled in by beamline acquisition system. Since as far as NeXus is concerned a fully populated file should leave the facility, this is nothing we have a strong opinion about. Writing an empty array (dimension 0) would work.
All resolved to everyone’s satisfaction.
NXmx, relative depends_on path
Not deemed required, for the moment.
Documentation, detector pixel origin
Eugen volunteered to have a look at this. Potentially including detector modules and related “new” areas.
Documentation, general review of tickets
Quite a number of tickets are open on the definitions repository, some of them very old. A good number of them could potentially be closed. Looking through them and at least commenting would help the next person make a decision. Action on all.
Plans for Code Camp an future
Eugen will advertise Code Camp on the mailing list shortly. Please have a think about ideas to tackle there and what we need to do strategically. Ideas so far include validation, NAPI, features.
example file repository
Is in need of new files. This would help developers to find bugs in their code and develop common data extraction methods. Maybe a github repo is not the best choice, for data size reasons. Might investigate at the code camp.
Next meeting will be Telco 20150630
Mark Basham suggests a scheme to attribute detector axes (like for an energy dispersive detector) analogue to NXdata. Not all detector must have an NXdata, otherwise that could be used directly. MK asserts that this looks good and we certainly should not have two schemes (NXdata vs NXdetector) to assign axes. Will revisit that at next telco.