Need an application definition that shows mixed use of NXreflections and NXmx

[phyy-nx]

The DIALS program dials.export makes these kind of files. See
https://github.com/nexusformat/exampledata/blob/master/DLS/reflections/hdf5/thaumatin_integrated.nxs

They look like this:

/entry:NXentry/experiment_0:NXsubentry <- this is Nxmx
/entry:NXentry/reflections:NXsubentry <- this is NXreflections

After #727 is fixed, they would look like this:

/entry:NXentry/experiment_0:NXsubentry <- this is Nxmx
/entry:NXentry/reflections:NXreflections

So the proposal is for an application definition for this use case. Or should NXreflections be added as an optional group in NXmx?

[prjemian]

NXreflections is a base class. NXmx is an application definition.
Inspired by figure in https://manual.nexusformat.org/classes/index.html, perhaps like this?

entry:NXentry
   experiment_0:NXsubentry
      definition="NXmx"
   reflections:NXreflections

or

entry:NXmx
   ... content required by NXnmx
   ... then this additional content
   reflections:NXreflections

[yayahjb]

Both -- it depends on the use case -- Herbert

…

On Thu, Jan 30, 2020 at 2:20 PM Aaron S. Brewster ***@***.***> wrote: The DIALS program dials.export makes these kind of files. See https://github.com/nexusformat/exampledata/blob/master/DLS/reflections/hdf5/thaumatin_integrated.nxs They look like this: /entry:NXentry/experiment_0:NXsubentry <- this is Nxmx /entry:NXentry/reflections:NXsubentry <- this is NXreflections After #727 <#727> is fixed, they would look like this: /entry:NXentry/experiment_0:NXsubentry <- this is Nxmx /entry:NXentry/reflections:NXreflections So the proposal is for an application definition for this use case. Or should NXreflections be added as an optional group in NXmx? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#748?email_source=notifications&email_token=ABB6EAI6RXV5QENTV2A5PULRAMSAHA5CNFSM4KN3O4Z2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IJ5ZUYQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB6EALQ5Y4CRVM4MKSPPHLRAMSAHANCNFSM4KN3O4ZQ> .

[mkoennecke]

Hi, Am 30.01.2020 um 20:20 schrieb Aaron S. Brewster <notifications@github.com<mailto:notifications@github.com>>: The DIALS program dials.export makes these kind of files. See https://github.com/nexusformat/exampledata/blob/master/DLS/reflections/hdf5/thaumatin_integrated.nxs They look like this: /entry:NXentry/experiment_0:NXsubentry <- this is Nxmx /entry:NXentry/reflections:NXsubentry <- this is NXreflections After #727<#727> is fixed, they would look like this: /entry:NXentry/experiment_0:NXsubentry <- this is Nxmx /entry:NXentry/reflections:NXreflections So the proposal is for an application definition for this use case. Or should NXreflections be added as an optional group in NXmx? — The second example feels clearly wrong, it should read: /experiment_0:NXentry <— This is NXmx /reflections:NXentry < — This follows the processed data convention and contains an NXreflection /reflections:NXentry/data:NXdata/reflections:NXreflections Because I think that reflections are actually processed data. You want to know how the reflections were extracted, parameters used and such. I feel that an application definition for processed reflection data is MIA. Best Regards, Mark Koennecke You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#748?email_source=notifications&email_token=ABGL7WTPIRHM6KD5NLYMYNTRAMSAHA5CNFSM4KN3O4Z2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IJ5ZUYQ>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABGL7WQ2KPSTH66AAIZKHK3RAMSAHANCNFSM4KN3O4ZQ>.

[phyy-nx]

Hi, let's discuss this on the next telco. I'll have the three options summarized on a slide and we can work out what makes sense and what needs to change.

[phyy-nx]

From Telco (group discussion): two action items to support multiple use cases

1. Add NXreflections as optional to NXmx (example use case: unmergered data from a single crystal)
2. Create separate application definition to bring many NXmx subentries together with a NXreflections. (example use case: merged data from multiple crystals)

[phyy-nx]

(reminder for me: on Telco it was mentioned that base classes cannot be entries or subenteries, but instead for the second case, NXreflections would be a child of the root NXentry)

Also: NXnote would be good for the 2nd case (the application definition) indicating how the NXreflections was derived)

Proposed name for application definition: NXreflection_list (additional options solicited :)

[phyy-nx]

Feedback from code camp: putative application definition: use multiple NXentry to distinguish between 'journaled' steps. How to indicate directionality between them? Eg. entry2 derives from entry1.

Example processing path in DIALS

1. Import
2. Find spots (depends on 1)
3. Index (depends 2)
4. Refine (depends on 3)
5. Find spots again (depends on 1)
6. Index again (depends on 5)
7. Index again (depends on 5)
8. Refine again (depends on 7)
9. Integrate (depends on 8)

Proposal: make each of the steps an NXentry with an NXprocess group. See https://manual.nexusformat.org/rules.html#content-of-a-processed-data-nxentry-group. Note, NXparameters could contain a path to the previous step! Maybe a field like parent_entry. Use links as much as possible to not copy things like NXmx or NXreflections.

[prjemian]

I'm removing the telco label for now since there is a clear course of action described in the previous comment.

[prjemian]

@phyy-nx: Should this remain on the list of code camp topics? If not, remove the code camp label as well.