XRD appdef draft #35
XRD appdef draft #35
Conversation
|
Here is the powder diffraction appdef we derive from: This is an interesting class to represent 2D detector scattering experiments: Some other interesting links:
|
I have added a bunch of recommendations / comments, hoping to improve the document.
|
There is also an eulerian cradle definition in nexus which encodes angular settings on a sphere: |
XRD/xrd.yaml
Outdated
| symbols: | ||
| # I would recommend using a bit more verbose symbol names, e.g. | ||
| # N_wavelengths, N_detectors | ||
| wlens: Number of wavlengths in the monochromated beam |
There was a problem hiding this comment.
This comment seems ill-defined to me. Wavelength is a continouts parameter. One could define a number of wavelength points or something. Also not clear to me why this should be part of the AppDef.
XRD/xrd.yaml
Outdated
| (NXxrd): | ||
| (NXentry): | ||
| # to me title makes no sense... acn we drop it? | ||
| title(NX_CHAR): |
There was a problem hiding this comment.
Is there a good reason this "extended title" field should be mandatory?
XRD/xrd.yaml
Outdated
| # move the time after the definition part | ||
| # because that part describes this document, all after it the experiment | ||
| start_time(NX_DATE_TIME): | ||
| doc: "Datetime of the start of the measurement" |
There was a problem hiding this comment.
Is this (qualitatively) different from the one in NXentry? Otherwise it's redundant, remove.
XRD/xrd.yaml
Outdated
| enumeration: ["NXxrd"] | ||
| (NXinstrument): | ||
| (NXsource): | ||
| type(NX_CHAR): |
There was a problem hiding this comment.
We can also add an enum here. there are only so many possible x-ray sources.
XRD/xrd.yaml
Outdated
| # if you expect to have wlens or N_wavelengts number of wavelength in the output, | ||
| # how can this be a single number? |
There was a problem hiding this comment.
This corresponds to the center wavelength. there is also wavelength_spread, that corresponds to a width.
the one in crystal corresponds probably to a spectrum.
There was a problem hiding this comment.
For any practical purposes, a single number, and potentially, the energy spread should typically be sufficient. The spectrum you can anyways store within the bae class fields if you believe it important.
There was a problem hiding this comment.
These parameters can also be multidemensional. You can always extend the dimensions in Nexus, as far as I know. I am thinking here e.g. about energy-dependent diffraction data at sychrotrons, where one scans the energy across an absorption edge and simultaneously moves all diffraction angles.
XRD/xrd.yaml
Outdated
| rotation_angle(NX_FLOAT): | ||
| doc: | | ||
| Optional rotation angle for the case when the powder | ||
| diagram has been obtained through an omega-2theta scan | ||
| like from a traditional single detector powder | ||
| diffractometer | ||
| unit: NX_ANGLE |
There was a problem hiding this comment.
Well, this is something special. I would also make this part of an NXtransformation, but we also need a field to specify that this kind of operation mode has been used, and which angle corresponds to the roation being used for this.
There was a problem hiding this comment.
Missing is an NXtransformation for the sample, and a depends_on
XRD/xrd.yaml
Outdated
| like from a traditional single detector powder | ||
| diffractometer | ||
| unit: NX_ANGLE | ||
| # should not this (monitor) more belong to the instrument / detector part? |
There was a problem hiding this comment.
I think Nxmonitor is somehow trated specially like NXdata in nexus. It can be a link to something in NXintrument, like NXdata typically is.
XRD/xrd.yaml
Outdated
| mode(NX_CHAR): | ||
| enumeration: ["monitor", "timer"] | ||
| doc: | | ||
| Count to a preset value based on either clock time (timer) | ||
| or received monitor counts (monitor). | ||
| preset(NX_FLOAT): | ||
| doc: Preset value for time or monitor | ||
| integral(NX_FLOAT): | ||
| doc: Total integral monitor counts | ||
| unit: NX_ANY |
There was a problem hiding this comment.
NXmonitor should be optional.
All the fields listed here should also be optional, or even not appear here, to my opinion. However, the one that really is important, data, is missing.
XRD/xrd.yaml
Outdated
| polar_angle(link): | ||
| doc: Should contain a link to polar angle in /NXentry/NXinstrument/NXdetector |
There was a problem hiding this comment.
this is too restrictive. Leave away, and let the people decide based on their NXtransformations and use case.
XRD/xrd.yaml
Outdated
| polar_angle(link): | ||
| doc: Should contain a link to polar angle in /NXentry/NXinstrument/NXdetector | ||
| data(link): | ||
| doc: Should contain a link to data in /Nxentry/Nxinstrument/Nxdetector |
There was a problem hiding this comment.
I would also not restrict it in this way. If people want to process their data (flat field correction, whatnot), they should do so in NXprocess entries, and then link NXdata to whatever endpoint of this chain they want to choose.
|
Hi @mkuehbach @tomio13 @rettigl @sunyue-xfel @cmmngr @sanbrock I added a part to account for different experimental angles with NXtransformations. I introduced a NXgoniometer to supply all of the angles (did not yet add the base class, though). I wrote all of the angles explicitly, even if we maybe should keep it a bit more open. But for now I thought it would be nice to have something more specific for discussion. Maybe we can discuss this shortly tomorrow in TF B meeting if we have time, @sanbrock @mkuehbach ? |
|
@RubelMozumder I noticed there are some ideas here that are not part of our current |
All of the core concepts have been available in the |
This is the cleaned XRD appdef yaml file. Please leave comments directly in the file so we can discuss (in Files changed tab). You may also comment in this thread for general discussions.
@aalbino2 @cmmngr @mkuehbach @tomio13 @rettigl