discussion on data types format for q_list (dynamic and static)

[ambarb]

So basically what do we want to support for the "labels of the q-bins for XPCS and I(Q) results?

Floats, tuples, lists, and strings:

• [x] q(r)
• [ ] q(r) with phi dependance
• [ ] (qx, qy, qz)
• [ ] (H, K, L)

Per @prjemian - NX wants these things to be 3 separate vectors (Nx crystal). Works for (H,K,L) and (qx, qy, qz), but sees less generalizable for the others.

Maybe doing this is more I/O hassle to on both side just to make a NX file?

@ambarb to make some various examples.

@prjemian thinks perhaps we need additional attribute to describe data.

[ambarb]

email to community out

[ambarb]

Community polled:

Please take a few minutes to weigh in on this matter.  The labels for q(r) dynamic q bins (or rois depending on your code base) is a straight forward list of scalars.  This list is very easy to iterate.  For other types of q informations (q(phi), (qx, qy, qz), (H,K,L) , (vert_pixel, horz_pixel) ) it seems like a list of tuples might be the correct approach, however this breaks with NX’s standards.  My concern in follow the NX standard is that it make code up file creation and file reading more cumbersome.  Therefore we have two options.  Please let me know which option you prefer

OPTION 1:  Keep list of tuples like below, and just create add some additional attributes to describe the data.

dynamic_q_list = [ (H1, K1, L1), (H2, K2, L2), ….. (Hn, Kn, Ln)  ]  # for n bins

OPTION 2:  follow the nexus convention, which means making each a single vector (or list-like thing). See below:

dynamic_q_list =
[ H1,  H2, ….. Hn ]  # for n bins
[ K1,  K2,  ….. Kn ]  # for n bins
[ L1,   L2,  ….. Ln ]  # for n bins

Option 1 was the only feedback I was received. I guess there real question is can this actually be:

• a large 1D array (or list) of tuples
• a large 1D array (or list) of strings
• a large 1D array (or list) of lists

• a large 1D array of floats

  The point was to not enforce a data type within the large 1D array so that this can be used flexibly.

  @prjemian what is the best way to go about this

[ambarb]

@AbbyGi and @prjemian I owe you example CHX results file with phi data

[prjemian]

Since we could use either tuples of h,k,l or text strings or something else, the only realistic option is option 1, a list of the bin descriptors.

[prjemian]

Q: Should we add an attribute which describes what type of information is in the list?

A: No, since the data type will be easily access from the HDF5 content itself. If we add an attribute, that might become out of sync with the data content.

Representation of each value is up to the user.

[prjemian]

Since it is not clear whether we should add an attribute (or field) that a data file writer would use to indicate how to use the information in the list (whether as tuple of hkl, as explicit |Q| values, ...), let's not define any of that now. This leaves it open to the community to request such a thing as they find it necessary or useful.

[prjemian]

@ambarb Is this issue still relevant?

[ambarb]

Still relevant. But I think we've decided how to deal with it in the Nexus defintion

File writers are a different discussion.

Let's leave this open until after we get past the first draft.