Telco 20150715


Wednesday, 15th July, 12:00 BST

Hangout Link:



Present: HJB, EW, MB, TSR (summer has apparently arrived everywhere in the northern hemisphere)

cmake for code

Eugen has made some progress and will have finished the configuration and build of the main library by the next meeting. Binding and tools will follow then, not necessarily in that order. hdf4 and xml should not be disabled by default but be integrated when available at least for this release. Equally building without hdf5 is not yet an error.

pull request 411

With the placeholder removed that seems a reasonable approach to fix issue 399, although not the final verdict for placeholders. But that may require a separate NXDL tweak. (Found out after the telco: PJ had one comment that the default “specified” should be specified. TSR commented in the ticket.)

Reducing number of open tickets

We closed 3 tickets during the telco and discussed issue 407 which Eugen will investigate.

scan dimensions for everything?

Rationale: Some fields, like instrument/name are unlikely to change during a scan. If scan rules didn’t apply an API could return nice and simple strings instead of arrays of them. Consensus: No change. Since for now we allow scan rules in all cases which is the most general way, having a special rule for a low number of fields is not deemed to help much. Rather have a simple rule than simple special cases. However: There are cases other than scan rules where dimensions can be added (detector/distance can be per pixel), so it should be clear what the added dimensions are. That’s unresolved for now.

3D detectors

fast and slow works for 2D. An extension for 3D might be fast, slow, slower or slowest. However if scan rules apply the slowest detector dimension may not be the slowest of the overall dataset. HJB suggests fast, second_fastest, third_fastest, fourth_fastest, fifth_fastest and so on ad nauseam as the general case. No real conclusion reached. The disconnect between fast/slow vs. x/y was not discussed.

CXI file format

The NeXus compliant version of it is so close to NeXus that integrating that as an application definition seems almost easy. We’ll invite them to the next teleconference.

Next conference

Telco 20150728