NXmpes liquidjet draft by domna · Pull Request #27 · FAIRmat-NFDI/nexus_definitions

domna · 2023-03-22T07:21:32Z

No description provided.

domna · 2023-04-17T06:34:45Z

contributed_definitions/nyaml/NXmpes_xps_liquid.yaml

+doc: This is the application definition for multidimensional photoelectron spectroscopy on liquids
+category: application
+NXmpes:
+  ENTRY(NXentry):


Writing ENTRY is not necessary. It is automatically inferred from writing (NXentry), i.e., there is always a conversion (NXsomething) -> SOMETHING(NXsomething) for groups.

domna · 2023-04-17T06:35:10Z

contributed_definitions/nyaml/NXmpes_xps_liquid.yaml

+    definition:
+      \@version(NX_CHAR):
+      enumeration: ["NXmpes_liquid"]
+    INSTRUMENT(NXinstrument):


INSTRUMENT may be remove, too

domna · 2023-04-17T06:39:50Z

contributed_definitions/nyaml/NXmpes_xps_liquid.yaml

+      enumeration: ["NXmpes_liquid"]
+    INSTRUMENT(NXinstrument):
+      energy_resolution(NX_FLOAT):
+      SOURCE(NXsource):


Remove SOURCE, too

domna · 2023-04-17T06:40:50Z

contributed_definitions/nyaml/NXmpes_xps_liquid.yaml

+        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):


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.

domna · 2023-04-17T06:41:22Z

contributed_definitions/nyaml/NXmpes_xps_liquid.yaml

+          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):


Here applies the same question as for beam_probe

domna · 2023-04-17T06:41:38Z

contributed_definitions/nyaml/NXmpes_xps_liquid.yaml

+        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):


Same question as for beam_probe

domna · 2023-04-17T06:41:53Z

contributed_definitions/nyaml/NXmpes_xps_liquid.yaml

+            exists: recommended
+            doc: "The space projected in the angularly dispersive directions, i.e. real or reciprocal."
+            enumeration: ["real", "reciprocal"]
+        ANALYSER_DISPERSIVE_ELEMENT(NXenergydispersion):


->beam_probe

domna · 2023-04-17T06:42:12Z

contributed_definitions/nyaml/NXmpes_xps_liquid.yaml

+          energy_scan_mode(NX_CHAR):
+            doc: "Way of scanning the energy axis (fixed or sweep)."
+            enumeration: ["fixed", "sweep"]
+          ENTRANCE_SLIT(NXaperture):


beam_probe

domna · 2023-04-17T06:42:19Z

contributed_definitions/nyaml/NXmpes_xps_liquid.yaml

+              pass_energy(NX_FLOAT):
+                unit: NX_LENGTH
+                doc: "The relevant dimension for the aperture (slit width, pinhole diameter etc)."
+        ELECTRON_DETECTOR(NXdetector):


beam_probe

domna · 2023-04-17T06:46:24Z

contributed_definitions/nyaml/NXmpes_xps_liquid.yaml

+              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):


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?

domna · 2023-04-17T06:51:57Z

contributed_definitions/nyaml/NXmpes_xps_liquid.yaml

+              enumeration: ["raw"]
+            raw(NX_NUMBER): # There is a block of numbers named raw.
+              doc: "Raw data before calibration."
+        GEOMETRY(NXtransformations):


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.

domna · 2023-04-17T06:58:26Z

It looks pretty good already. There are a few points which need some work:

I think we can go in the direction of writing this as a sub-definition of NXmpes. We then only have to state additional fields and changes in this file. We denote this by the extends keyword on top of the file.
A group can be written shortly with (NXentry) instead of ENTRY(NXentry)
There are some groups (written in upper case), which I think should be written in lower case. Lower case means that there exists exactly one field with this exact name. Upper case means that there is a group with this name and the fields can be named arbitrarily.
The representation of NXtransformations is intended differently and there should be a transformation attached to the respective instrument part. I can assist you with doing appropriate changes in your example file to show to you how it works. Here is the documentation on NXtransformation which shows the idea.

contributed_definitions/nyaml/NXmpes_liquid.yaml

domna · 2023-06-08T10:37:12Z

contributed_definitions/nyaml/NXmpes_liquid.yaml

-              \@units: NX_ANGLE
+              unit: NX_ANGLE
              \@vector(NX_NUMBER):
            rot_y(NX_NUMBER):


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?

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.

contributed_definitions/nyaml/NXmpes_liquid.yaml

domna · 2023-06-08T10:43:44Z

@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 depends_on field in the appropriate groups.

contributed_definitions/nyaml/NXmpes_liquid.yaml

domna · 2023-11-03T13:53:14Z

Closed in favour of #104

domna added 2 commits March 22, 2023 08:20

Adds liquidjet draft

866951a

Adds Stephans changes for mpes_liquid

5108591

domna commented Apr 17, 2023

View reviewed changes

domna added 2 commits June 8, 2023 11:26

Latest changes from Stephan at 02.06.23

25d552b

Cleanup

cd117f1

domna commented Jun 8, 2023

View reviewed changes

contributed_definitions/nyaml/NXmpes_liquid.yaml Outdated Show resolved Hide resolved

domna commented Jun 8, 2023

View reviewed changes

contributed_definitions/nyaml/NXmpes_liquid.yaml Outdated Show resolved Hide resolved

domna commented Jun 8, 2023

View reviewed changes

contributed_definitions/nyaml/NXmpes_liquid.yaml Outdated Show resolved Hide resolved

domna commented Jun 8, 2023

View reviewed changes

contributed_definitions/nyaml/NXmpes_liquid.yaml Show resolved Hide resolved

Removes fields already present in NXmpes and adds depends_on fields

62e947a

domna changed the title ~~NXmpes XPS liquidjet draft~~ NXmpes liquidjet draft Jul 4, 2023

domna commented Jul 4, 2023

View reviewed changes

contributed_definitions/nyaml/NXmpes_liquid.yaml Outdated Show resolved Hide resolved

domna added 2 commits July 5, 2023 08:46

Prefix solvent and solute groups

7ccc2e8

Adds nxdl

9648caf

domna mentioned this pull request Aug 9, 2023

NXmpes refactoring #52

Merged

domna mentioned this pull request Oct 24, 2023

Finalize sub-appdefs #90

Closed

4 tasks

domna closed this Nov 3, 2023

domna deleted the mpes-liquidjet branch January 15, 2024 15:51

Conversation

domna commented Mar 22, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

domna commented Apr 17, 2023

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

domna commented Jun 8, 2023

Uh oh!

Uh oh!

domna commented Nov 3, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants