XPCS Ontology

[qzhang234]

The .zip file contains:

1. XPCS ontology (.doc)
2. Sample result file based on the ontology (.hdf)

The .hdf file can be viewed in any standard hdf viewer and can be read out item-by-item using the h5py package in python.

Ontology_and_Sample_Result.zip

[ronpandolfi]

Hi QZ,

Here are a few ideas to make the XPCS ontology more in line with the design principles of nexus:

• What will be the name of this application definition? What will be its Groups? structure?
• Many of the "Variable Dimensions" seem redundant. All NXData implicitly have a shape attribute. Some are also present in NXdetector. Would these fields be top-level?
• Why is there a "0" in "Norm-0-..."? Is this intended to support multiple g2 curves?
• There are already fields for I vs q in NXcanSAS. I suggest eliminating "partition-mean-total" and "partition-mean-partial" as first-class fields in the XPCS spec
• The convention for nexus field names seems to be snake_case. I suggest adopting this style.
• The second row of "frameSum" should be eliminated; it is implicit.
• "frameSum" and "pixelSum" seem relevant outside of XPCS. Can they be moved to a more general spec?
• Detector "exposure_period" is already covered by NXsas. Alternatively, should we aim to cover non-uniform exposure periods (i.e. log-scale time acquisition)?
• "analysis_type" should be an object attribute; what is the object type? Should "/xpcs/" be a NXData or something more specific?
• What is the difference between "static" and "dynamic" partitions?
• "partition" implies mutually exclusive; is ROI a better term?
• I'm surprised that there's no definition for ROIs or "partitions" in NXcanSAS. I'd be curious to know if there is a reason for its exclusion; otherwise, it should be added to that spec.
• "/exchange" is a dataexchange convention, and should be removed/renamed.

I suggest taking a close look at the other nexus application definitions and mimicking their documentation layout as way to make this fit nexus better.

Edit:
Here are some links for your reference:

• NeXus Base Definitions: http://download.nexusformat.org/doc/html/classes/base_classes/index.html#base-class-definitions
• NeXus Application Definitions: http://download.nexusformat.org/doc/html/classes/applications/index.html#application-definitions
• NXsas: http://download.nexusformat.org/doc/html/classes/applications/NXsas.html#nxsas
• NXcanSAS: http://download.nexusformat.org/doc/html/classes/applications/NXcanSAS.html#nxcansas

[ambarb]

@qzhang234 Do you all use AreaDetector to control the CCD?

[qzhang234]

@ambarb We currently do not at 8-ID-I. As far as I recall Yugang uses a Eiger 1M for WA-XPCS and Eiger 4M for SA-XPCS. I'm not sure what ALS uses. Maybe they use CCD because it's soft x-ray?

[stuartcampbell]

Thank you @qzhang234 this is a great start. I am hopeful that as there isn't an XPCS NeXus definition, we can be the ones to come up with the standard! 😄

[ronpandolfi]

@qzhang234 COSMIC-XPCS has both a "FastCCD" (same model as CSX), and a Timepix (comparable to your Medipix) detector.

I think @ambarb was referring to the AreaDetector plugin in EPICS. Are 8-ID-I's Eiger detectors not EPICS IOCs?

[qzhang234]

@ronpandolfi @ambarb For 8-ID-I's Lambda, we are using EPICS IOCs for sure. The new Rigaku one is still under R&D but it will have EPICS IOC starting from 2020 Spring.

I'm not entirely sure what CHX is using for their Eigers

[ambarb]

I ask about EPICS AreaDetector because NSLS-II has tried to keep the metadata keys as close as possible to the EPICS PV names. For instance, In AreaDetector, that data from individual exposures are are called images as opposed to frames. Much of this is done by ophyd and bluesky so that beamlines at NSLS-II are consistent. I am suggesting we go with a similar approach so that things are a transparent and intuitive - which is important for staff going between beamlines.

CHX also use EPICS AreaDetector (or at least that is what their profile indicates). They should have very similar metadata keys as CSX, unless they renamed them manually.

[qzhang234]

@ronpandolfi Does COSMIC-XPCS do both small and wide angle XPCS? What is the detector distance in each case? And is the detector distance usually fixed?

[ronpandolfi]

@qzhang234 I suggest asking Roland or Sujoy for beamline information.

[ambarb]

XPCS_Ontology_revisit.docx

discussed QZ's original post and began google document with @qzhang234 and others.
Inquire if you would like read or write access to the google document. I think I got everyone for read, but I missed Ron and Tom.