ENH: first pass at ingesting nexus files

[tacaswell]

Based on chopper.nxs from nexpy examples

attn @stuartcampbell

[codecov-io]

Codecov Report

Merging #28 into master will decrease coverage by 6.1%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master      #28      +/-   ##
==========================================
- Coverage   96.38%   90.28%   -6.11%     
==========================================
  Files           5        6       +1     
  Lines         858      916      +58     
==========================================
  Hits          827      827              
- Misses         31       89      +58

Impacted Files	Coverage Δ
suitcase/nexus.py	0% <0%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 92c1094...f9042fa. Read the comment docs.

[stuartcampbell]

How do we test this ? Wouldn't we need to store the chopper.nxs file somewhere ?

My first reaction is that we should change the name as it is for a very specific NeXus definition. I'll get the file and have a look at it to see which "application" definition it is adhering to. Then maybe call it something like nexus_directtof.py.

[tacaswell]

What are the application names from the chopper file and the format that Pete wrote?

[stuartcampbell]

@prjemian Just wondering on your thoughts about the suggestion to 'partition' the NeXus code by application definition type ? Does that seem sensible ? If so, what IDF does your file correspond to ?

[prjemian]

I don't understand idf type, yet. Can you help me there?

…

On May 2, 2017 3:37 PM, "Stuart Campbell" ***@***.***> wrote: @prjemian <https://github.com/prjemian> Just wondering on your thoughts about the suggestion to 'partition' the NeXus code by IDF type ? Does that seem sensible ? If so, what IDF does your file correspond to ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACLKMO6ZsetQD_O7pGjZxiTMSgPTn_o9ks5r15PqgaJpZM4MReCd> .

[stuartcampbell]

Sorry @prjemian I mistyped! I mean the application definition ?

[prjemian]

I believe I was shooting for a plain NXentry group with NXinstrument subgroup and linked content in NXdata group. There is no application definition now that is sufficiently generic.

We could create our own application definition and that may be useful to give a defined interface. Comments?

[stuartcampbell]

I must admit this was part of my fiendish plan was to make this type of file a new nexus definition. I don't think we need to have a hard/strict format yet (as it is bound to change as we learn more) but any suggestions on a name ?

[prjemian]

First idea: NXbluesky (as NXsuitcase seems suggestive yet so non-descriptive)

[prjemian]

Here is the initial NeXus schema (from the source code):

NXroot
    @default = name of first NXentry group
    NXentry (one for each header)
        @default = name of first NXdata group
        descriptor_name:NXlog (one for each descriptor)
            dataset (one for each data_key)
                @axes = name of dataset_timestamps if provided
            dataset_timestamps (one for each data_key timestamps if provided)
        descriptor_name_data:NXdata (one for each descriptor)
            @signal = name of first dataset in this group
            dataset (HDF5 hard link to original dataset in NXlog group)
            dataset_timestamps (HDF5 hard link to original dataset_timestamps in NXlog group if provided)

But that needs improvement as begin to better understand what information is standard in the start and event descriptors documents

[stuartcampbell]

Shouldn't this be ingest_nexus ?

[tacaswell]

@klauer and @danielballan have already thoroughly pointed out this error.

[stuartcampbell]

Sorry - didn't notice and couldn't find their comments.