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 commented 7 years ago

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 commented 7 years ago

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

stuartcampbell commented 7 years ago

@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 commented 7 years ago

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

On May 2, 2017 3:37 PM, "Stuart Campbell" notifications@github.com 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 https://github.com/NSLS-II/suitcase/pull/28#issuecomment-298753544, or mute the thread https://github.com/notifications/unsubscribe-auth/ACLKMO6ZsetQD_O7pGjZxiTMSgPTn_o9ks5r15PqgaJpZM4MReCd .

stuartcampbell commented 7 years ago

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

prjemian commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

prjemian commented 7 years ago

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

bluesky / suitcase-core

ENH: first pass at ingesting nexus files #28

Codecov Report