Merge pull request #282 from FAIRmat-NFDI/add_workshop_notes_from_ell…

…ip_and_raman Most changes here are just notes - Many todos were added, which have to be included for a future rework.
FAIRmat-NFDI · Sep 9, 2024 · 6054ae7 · 6054ae7
2 parents 98d6784 + e1a9984
commit 6054ae7
Show file tree

Hide file tree

Showing 6 changed files with 126 additions and 31 deletions.
diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml
@@ -23,7 +23,21 @@
 -->
 <!--
 04/2024
-A rework of the draft version(06/2022) of a NeXus application definition for ellipsometry.-->
+A rework of the draft version(06/2022) of a NeXus application definition for ellipsometry.
+
+09/2024
+TODO (Workshop output):
+- Better categorization of ellipsoeter types:
+    Seperate in spectral range and measurement types (In situ vs infrared?? This grouping does not make sense)
+    Maybe make a given special field for "spectral_range" with units of eV or nm?
+- Add a StepScanAnalzer as measurement type (continous/rotating mode the other? Ask Chris)
+- Redefine more/higher requirements for Ellipsometry compared to NXoptical_spectroscopy: Especially incident angle and polarization.
+- Refinements for ellipsometer_type and add ellipsometer_method/mode:
+   "~ please consider renaming "ellipsometer_type" to "ellipsometer_method" or "ellipsometer_mode". Motivation: "rotating_compensator" etc. are methods of ellipsometry measurements, and some ellipsometers support multiple methods (e.g. rotating compensator, nulling etc).
+   ~ please consider to use the field "ellipsometer_type" for entries directly related to the core instrument, i.e. "imaging ellipsometer",  "standard ellipsometer" (or: "non-imaging ellipsometer"), maybe others such as "back-focal plane ellipsometer"  "
+- Add a clear predefined data structure, as initially proposed, but dont add any restrictions regarding dimensions
+    Make ois maybe similar to NXdata_mpes. In this way, at all FAIR assignments of the data is possible. As well use this to guide the people, to let them know, where they have to save their data. Just use NXdata is too vague. Could be easing the threshold to get into NeXus.
+    This explicitly refers to a wish to add: "exposure time, number of scans"-->
 <definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="application" type="group" name="NXellipsometry" extends="NXoptical_spectroscopy" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
     <symbols>
         <doc>
@@ -170,8 +184,15 @@ A rework of the draft version(06/2022) of a NeXus application definition for ell
                     <item value="phase modulation"/>
                     <item value="imaging ellipsometry"/>
                     <item value="null ellipsometry"/>
+                    <item value="other"/>
                 </enumeration>
             </field>
+            <field name="ellipsometer_type_other">
+                <doc>
+                     If the ellipsometer_type is `other`, a specific ellipsometry_type" should be
+                     added here.
+                </doc>
+            </field>
             <field name="rotating_element_type">
                 <doc>
                      Define which element rotates, e.g. polarizer or analyzer.
@@ -188,7 +209,16 @@ A rework of the draft version(06/2022) of a NeXus application definition for ell
                      If focussing probes (lenses) were used, please state if the data
                      were corrected for the window effects.
                 </doc>
-                <!--This as well can be stated in window/aperture-->
+                <field name="type">
+                    <enumeration>
+                        <item value="objective"/>
+                        <item value="lens"/>
+                        <item value="glass fiber"/>
+                        <item value="none"/>
+                        <item value="other"/>
+                    </enumeration>
+                </field>
+                <group name="device_information" type="NXfabrication" optional="true"/>
                 <field name="data_correction" type="NX_BOOLEAN" recommended="true">
                     <doc>
                          Were the recorded data corrected by the window effects of the

diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml
@@ -32,7 +32,12 @@ TODO:
 - Make spectralfilter_TYPE(NXbeam_device) own base class -\-> extend NXfilter?  and add them to NXinstrument.
 - Make offset angles for polar and azimutal?
 - Can angle_reference_frame be replaced later by only using reference_frames and generic angle description?
-- Add optical elements and rework them: NXfiber, NXbeam_splitter,-->
+- Add optical elements and rework them: NXfiber, NXbeam_splitter,
+- Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured?
+- Is there something to describe the spot size?
+- Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) -\-> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?"
+- How to describe beam size properties? NXbeam/extend? Is this enough? or do we need more abitrary shapes as elliptically? Maybe as well focus spot size?
+- Think of removing/reworking of (optional) NXfabrications? Con: bloats up the NeXus def (move it to base classes?) Pro: as the fixed name device_information is used, the structure is more FAIR / clean designed?-->
 <definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="application" type="group" name="NXoptical_spectroscopy" extends="NXobject" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
     <symbols>
         <doc>
@@ -319,14 +324,14 @@ TODO:
                     </doc>
                     <enumeration>
                         <item value="CCD"/>
-                        <item value="Photomultiplier"/>
-                        <item value="Photodiode"/>
-                        <item value="Avalanche-Photodiode"/>
-                        <item value="Streak Camera"/>
-                        <item value="Bolometer"/>
-                        <item value="Golay Detectors"/>
-                        <item value="Pyroelectric Detector"/>
-                        <item value="Deuterated Triglycine Sulphate"/>
+                        <item value="photomultiplier"/>
+                        <item value="photodiode"/>
+                        <item value="avalanche-photodiode"/>
+                        <item value="streak camera"/>
+                        <item value="bolometer"/>
+                        <item value="golay detectors"/>
+                        <item value="pyroelectric detector"/>
+                        <item value="deuterated triglycine sulphate"/>
                         <item value="other"/>
                     </enumeration>
                 </field>
@@ -400,6 +405,9 @@ TODO:
                         <item value="halogen lamp"/>
                         <item value="LED"/>
                         <item value="mercury cadmium telluride"/>
+                        <item value="deuterium lamp"/>
+                        <item value="xenon lamp"/>
+                        <item value="globar"/>
                         <item value="other"/>
                     </enumeration>
                 </field>
@@ -662,10 +670,10 @@ TODO:
                          defined incident or scattered light state.
                     </doc>
                     <enumeration>
-                        <item value="Polarization by Fresnel reflection"/>
-                        <item value="Birefringent polarizers"/>
-                        <item value="Thin film polarizers"/>
-                        <item value="Wire-grid polarizers"/>
+                        <item value="polarization by Fresnel reflection"/>
+                        <item value="birefringent polarizers"/>
+                        <item value="thin film polarizers"/>
+                        <item value="wire-grid polarizers"/>
                         <item value="other"/>
                     </enumeration>
                 </field>
@@ -693,7 +701,7 @@ TODO:
                     <enumeration>
                         <item value="long-pass filter"/>
                         <item value="short-pass filter"/>
-                        <item value="Notch filter"/>
+                        <item value="notch filter"/>
                         <item value="reflection filter"/>
                         <item value="neutral density filter"/>
                         <item value="other"/>

diff --git a/contributed_definitions/NXraman.nxdl.xml b/contributed_definitions/NXraman.nxdl.xml
@@ -29,6 +29,22 @@ N_incident_beams: |
 <!--
 04/2024
 A draft version of a NeXus application definition for Raman spectroscopy.-->
+<!--
+09/2024
+TODO (Workshop output):
+- Talk with VIBSO people - possible to syncrhonize raman_experiment_type with this ontology?
+- Similar to ellipsometry: Seperate in-situ from resonant/non-resonant stuff: OR maybe allow multiple selections?
+- Shorten raman_experiment_type by removal of Raman_spectroscopy, but as well fix the Raman Reader in the same run
+- Which for more dataconverters: Output from usualy Raman setups to neXus format?
+- Spot size description?
+- Descroption of defocusing / maybe as well as experiment_type?
+
+Wishes for NXraman or general next workshop:
+"convert excisting data to NeXus"
+"dictionary lookup keywords/fields in existing formats"(?)
+Template for specific experiments (i.e. too complex to get into NeXus/FAIRdata?) - unclear what to do.
+coorporation with VIBSO ontology?
+dataset examples (i.e. NXdata_raman)-->
 <definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="application" type="group" name="NXraman" extends="NXoptical_spectroscopy" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
     <symbols>
         <doc>
@@ -173,16 +189,17 @@ A draft version of a NeXus application definition for Raman spectroscopy.-->
                 <item value="resonant Raman spectroscopy"/>
                 <item value="non-resonant Raman spectroscopy"/>
                 <item value="Raman imaging"/>
-                <item value="Tip-enhanced Raman spectroscopy (TERS)"/>
-                <item value="Surface-enhanced Raman spectroscopy (SERS)"/>
-                <item value="Surface plasmon polariton enhanced Raman scattering (SPPERS)"/>
-                <item value="Hyper Raman spectroscopy (HRS)"/>
-                <item value="Stimulated Raman spectroscopy (SRS)"/>
-                <item value="Inverse Raman spectroscopy (IRS)"/>
-                <item value="Coherent anti-Stokes Raman spectroscopy (CARS)"/>
+                <item value="tip-enhanced Raman spectroscopy (TERS)"/>
+                <item value="surface-enhanced Raman spectroscopy (SERS)"/>
+                <item value="surface plasmon polariton enhanced Raman scattering (SPPERS)"/>
+                <item value="hyper Raman spectroscopy (HRS)"/>
+                <item value="stimulated Raman spectroscopy (SRS)"/>
+                <item value="inverse Raman spectroscopy (IRS)"/>
+                <item value="coherent anti-Stokes Raman spectroscopy (CARS)"/>
                 <item value="other"/>
             </enumeration>
         </field>
+        <!--     enumeration: [in situ, resonant, non-resonant, imaging, tip-enhanced (TERS), surface-enhanced (SERS), surface plasmon polariton enhanced (SPPERS), hyper Raman spectroscopy (HRS), stimulated (SRS), inverse (IRS), coherent anti-Stokes (CARS), other]-->
         <field name="raman_experiment_type_other" optional="true">
             <doc>
                  If the raman_experiment_type is `other`, a name should be specified here.

diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml
@@ -62,7 +62,20 @@ symbols:
 
 # 04/2024
 # A rework of the draft version(06/2022) of a NeXus application definition for ellipsometry.
-
+#
+# 09/2024
+# TODO (Workshop output):
+# - Better categorization of ellipsoeter types:
+#     Seperate in spectral range and measurement types (In situ vs infrared?? This grouping does not make sense)
+#     Maybe make a given special field for "spectral_range" with units of eV or nm?
+# - Add a StepScanAnalzer as measurement type (continous/rotating mode the other? Ask Chris)
+# - Redefine more/higher requirements for Ellipsometry compared to NXoptical_spectroscopy: Especially incident angle and polarization.
+# - Refinements for ellipsometer_type and add ellipsometer_method/mode:
+#    "~ please consider renaming "ellipsometer_type" to "ellipsometer_method" or "ellipsometer_mode". Motivation: "rotating_compensator" etc. are methods of ellipsometry measurements, and some ellipsometers support multiple methods (e.g. rotating compensator, nulling etc).
+#    ~ please consider to use the field "ellipsometer_type" for entries directly related to the core instrument, i.e. "imaging ellipsometer",  "standard ellipsometer" (or: "non-imaging ellipsometer"), maybe others such as "back-focal plane ellipsometer"  "
+# - Add a clear predefined data structure, as initially proposed, but dont add any restrictions regarding dimensions
+#     Make ois maybe similar to NXdata_mpes. In this way, at all FAIR assignments of the data is possible. As well use this to guide the people, to let them know, where they have to save their data. Just use NXdata is too vague. Could be easing the threshold to get into NeXus.
+#     This explicitly refers to a wish to add: "exposure time, number of scans"
 type: group
 NXellipsometry(NXoptical_spectroscopy):
   (NXentry):
@@ -100,7 +113,10 @@ NXellipsometry(NXoptical_spectroscopy):
       ellipsometer_type:
         doc: |
           What type of ellipsometry was used? See Fujiwara Table 4.2.
-        enumeration: [rotating analyzer, rotating analyzer with analyzer compensator, rotating analyzer with polarizer compensator, rotating polarizer, rotating compensator on polarizer side, rotating compensator on analyzer side, modulator on polarizer side, modulator on analyzer side, dual compensator, phase modulation, imaging ellipsometry, null ellipsometry]
+        enumeration: [rotating analyzer, rotating analyzer with analyzer compensator, rotating analyzer with polarizer compensator, rotating polarizer, rotating compensator on polarizer side, rotating compensator on analyzer side, modulator on polarizer side, modulator on analyzer side, dual compensator, phase modulation, imaging ellipsometry, null ellipsometry, other]
+      ellipsometer_type_other:
+        doc: |
+          If the ellipsometer_type is `other`, a specific ellipsometry_type" should be added here.
       rotating_element_type:
         doc: |
           Define which element rotates, e.g. polarizer or analyzer.
@@ -110,7 +126,10 @@ NXellipsometry(NXoptical_spectroscopy):
         doc: |
           If focussing probes (lenses) were used, please state if the data
           were corrected for the window effects.
-        # This as well can be stated in window/aperture
+        type:
+          enumeration: [objective, lens, glass fiber, none, other]
+        device_information(NXfabrication):
+          exists: optional
         data_correction(NX_BOOLEAN):
           exists: recommended
           doc: |

diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml
@@ -34,6 +34,11 @@ symbols:
 # - Make offset angles for polar and azimutal? 
 # - Can angle_reference_frame be replaced later by only using reference_frames and generic angle description?
 # - Add optical elements and rework them: NXfiber, NXbeam_splitter, 
+# - Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured?
+# - Is there something to describe the spot size?
+# - Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) --> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?"
+# - How to describe beam size properties? NXbeam/extend? Is this enough? or do we need more abitrary shapes as elliptically? Maybe as well focus spot size?
+# - Think of removing/reworking of (optional) NXfabrications? Con: bloats up the NeXus def (move it to base classes?) Pro: as the fixed name device_information is used, the structure is more FAIR / clean designed?
 type: group
 NXoptical_spectroscopy(NXobject):
   (NXentry):
@@ -240,7 +245,7 @@ NXoptical_spectroscopy(NXobject):
           exists: recommended
           doc: |
             Description of the detector type.
-          enumeration: [CCD, Photomultiplier, Photodiode, Avalanche-Photodiode, Streak Camera, Bolometer, Golay Detectors, Pyroelectric Detector, Deuterated Triglycine Sulphate, other]
+          enumeration: [CCD, photomultiplier, photodiode, avalanche-photodiode, streak camera, bolometer, golay detectors, pyroelectric detector, deuterated triglycine sulphate, other]
         detector_type_other:
           exists: optional
           doc: |
@@ -297,7 +302,7 @@ NXoptical_spectroscopy(NXobject):
         exists: recommended
         type:
           exists: recommended
-          enumeration: [laser, dye-laser, broadband tunable light source, X-ray Source, arc lamp, halogen lamp, LED, mercury cadmium telluride, other]
+          enumeration: [laser, dye-laser, broadband tunable light source, X-ray Source, arc lamp, halogen lamp, LED, mercury cadmium telluride, deuterium lamp, xenon lamp, globar, other]
         type_other:
           exists: optional
           doc: |
@@ -524,7 +529,7 @@ NXoptical_spectroscopy(NXobject):
           doc: |
             Physical principle of the polarization filter used to create a
             defined incident or scattered light state.
-          enumeration: [Polarization by Fresnel reflection, Birefringent polarizers, Thin film polarizers, Wire-grid polarizers, other]
+          enumeration: [polarization by Fresnel reflection, birefringent polarizers, thin film polarizers, wire-grid polarizers, other]
         specific_polarization_filter_type(NX_CHAR):
           exists: optional
           doc: |
@@ -545,7 +550,7 @@ NXoptical_spectroscopy(NXobject):
           doc: |
             Type of laserline filter used to supress the laser, if measurements
             close to the laserline are performed.
-          enumeration: [long-pass filter, short-pass filter, Notch filter, reflection filter, neutral density filter, other]
+          enumeration: [long-pass filter, short-pass filter, notch filter, reflection filter, neutral density filter, other]
         intended_use:
           exists: optional
           doc: |