NXmpes liquidjet draft #27
Conversation
| doc: This is the application definition for multidimensional photoelectron spectroscopy on liquids | ||
| category: application | ||
| NXmpes: | ||
| ENTRY(NXentry): |
There was a problem hiding this comment.
Writing ENTRY is not necessary. It is automatically inferred from writing (NXentry), i.e., there is always a conversion (NXsomething) -> SOMETHING(NXsomething) for groups.
| definition: | ||
| \@version(NX_CHAR): | ||
| enumeration: ["NXmpes_liquid"] | ||
| INSTRUMENT(NXinstrument): |
| enumeration: ["NXmpes_liquid"] | ||
| INSTRUMENT(NXinstrument): | ||
| energy_resolution(NX_FLOAT): | ||
| SOURCE(NXsource): |
| probe(NX_CHAR): | ||
| doc: "Type of probe. In photoemission it's always photons, so the full NIAC list is restricted." | ||
| enumeration: ["x-ray", "ultraviolet", "visible light"] | ||
| BEAM_PROBE(NXbeam): |
There was a problem hiding this comment.
This is a group with the name BEAM_PROBE, i.e., there may be fields written BEAM_PROBE[any_name]. Is this the intention or should it rather be a field named beam_probe? In this case it has to be written in lower case.
| doc: "Incident polarization specified as a Stokes vector." | ||
| \@units(NX_CHAR): | ||
| doc: "The units for this observable are not included in the NIAC list. Responsibility on correct formatting and parsing is handed to the user by using ‘NX_ANY’. Correct parsing can still be implemented by using this attribute. Fill with: The unit unidata symbol if the unit has one (Example: ‘T’ for the unit of magnetic flux density tesla). The unit unidata name if the unit has a name (Example: ‘farad’ for capacitance). A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. Example: for lightsource brilliance (SI) ‘1/(s.mm2.mrad2)’. Here: SI units are ‘V2/m2’." | ||
| ANALYZER(NXelectronanalyser): |
There was a problem hiding this comment.
Here applies the same question as for beam_probe
| slow_axes(NX_CHAR): | ||
| exists: optional | ||
| doc: "List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. See fast_axes for examples." | ||
| ANALYSER_LENS_SYSTEM(NXcollectioncolumn): |
| exists: recommended | ||
| doc: "The space projected in the angularly dispersive directions, i.e. real or reciprocal." | ||
| enumeration: ["real", "reciprocal"] | ||
| ANALYSER_DISPERSIVE_ELEMENT(NXenergydispersion): |
| energy_scan_mode(NX_CHAR): | ||
| doc: "Way of scanning the energy axis (fixed or sweep)." | ||
| enumeration: ["fixed", "sweep"] | ||
| ENTRANCE_SLIT(NXaperture): |
| pass_energy(NX_FLOAT): | ||
| unit: NX_LENGTH | ||
| doc: "The relevant dimension for the aperture (slit width, pinhole diameter etc)." | ||
| ELECTRON_DETECTOR(NXdetector): |
| doc: "The vector in the direction of gravity." | ||
| \@depends_on(NX_CHAR): | ||
| doc: "Set to '.' to specify the normal vector to which all other vectors are related." | ||
| beam_axis(NX_NUMBER): |
There was a problem hiding this comment.
Typically, in NeXus the McStas coordinate system is chosen. There, the beam_axis is always along the z-axis. What is the intention here to state it in the file?
| enumeration: ["raw"] | ||
| raw(NX_NUMBER): # There is a block of numbers named raw. | ||
| doc: "Raw data before calibration." | ||
| GEOMETRY(NXtransformations): |
There was a problem hiding this comment.
The general idea of NXtransformations is different. It is intended as transformation matrices attached to an instrument part, i.e., the analyzer would have a transformation matrix attached to transform a coordinate system into its frame.
|
It looks pretty good already. There are a few points which need some work:
|
| @@ -98,119 +21,57 @@ NXmpes_liquid(NXmpes): | |||
| doc: "Is '.', since beam axis is assumed to be horizontal (perpendicular to gravity)." | |||
| \@transformation_type(NX_CHAR): | |||
| enumeration: ["rotation"] | |||
| \@units: NX_ANGLE | |||
| unit: NX_ANGLE | |||
| \@vector(NX_NUMBER): | |||
| rot_y(NX_NUMBER): | |||
There was a problem hiding this comment.
Here the question is whether the users should have to follow a certain transformation chain. In principle they could use any chain they want here. Do you have a certain reason why it is better to demand this specific kind of transformation chain?
There was a problem hiding this comment.
I think this can be open to the user and inherited from the MPES definition. From my POV, we do not require anything specific for defining the detection system / analyzer. However, if a flatjet is present, its orientation (surface normal) is defined with respect to the lens axis. However, I believe this is a similar situation with ARPES, where the surface normal is defined for sample rotation.
Also, this might change in the future, if people want to specify something like differential pumping stages / orifices, which are an integral component of liquid PES experiments as compared to UHV PES. For now, I don't see such a requirement, though.
|
@stthuermer The changes are very nice already. I tidied the definition up, because we now properly support using subdefinitions from NXmpes so we don't have to respecify what is there already. Please have a look if I did it correctly. Other then that the transformations look good but the question is whether you really want to demand this exact transformation chain from the users or if you rather specify that transformations should be present by required a |
|
Closed in favour of #104 |
No description provided.