Comments on NXluminescence.yaml #36

jlaehne · 2022-07-22T14:24:45Z

This PR serves to comment on the current version of the NXluminescence proposal.
(work in progress, to be continued).

This PR serves to comment on the current version of the NXluminescence proposal. (to be continued).

domna · 2022-07-26T13:28:12Z

optical_spectroscopy/luminescence/NXluminescence.yaml

@@ -155,19 +155,23 @@ symbols:
      luminescence_type:
        enumeration: [photoluminescence, cathodoluminescence, electroluminescence,
          x-rays, sonoluminescence, chemiluminescence, bioluminescence]
+      # 'x-ray fluorescence' instead of 'x-rays'?


I would say that X-ray fluorescence is just a particular case of photoluminescence or is there a good reason to separate those two?

Well, the excitation sources will be quite different (and photoluminescence is usually associated with laser/lamp exciation), so a disambiguation would make sense I guess.

And in X-ray you may have energy resolved detectors without spectrograph/monochromator elements.

domna · 2022-07-26T13:29:17Z

optical_spectroscopy/luminescence/NXluminescence.yaml

@@ -155,19 +155,23 @@ symbols:
      luminescence_type:
        enumeration: [photoluminescence, cathodoluminescence, electroluminescence,
          x-rays, sonoluminescence, chemiluminescence, bioluminescence]
+      # 'x-ray fluorescence' instead of 'x-rays'?

      excitation(NXsubentry):


NXsubentry doesn't make so much sense here. It is intended to include an appdef inside the experiment to support multiple experiments carried out at the same time at e.g. the same beam line. It also has to have a definition as a mandatory field which is not given here.

Well, it is descriptive in its name... or we can have NXobject? It is a group of parameters which do not belong to a single base class.

domna · 2022-07-26T13:31:53Z

optical_spectroscopy/luminescence/NXluminescence.yaml

@@ -212,13 +223,16 @@ symbols:
              element/monochromator, and a detector. Describe the beam path 
              between the sample and the detection unit in beam_path_after."

+        # 'beam_path_detection' instead of 'beam_path_after'?
+        # optical elements can be before or after the spectrometer (which can also be left out
+        # when working with filters only -> so maybe move spectrometer to the beam path>)


I agree. This would also allow to add a spectrometer in the excitation beam path which would allow for representing line scan experiments.

It would also allow for dual or triple monochromator setups

Yes, and "photoluminescence excitation (PLE)", where a monochromator comes after the lamp.

An optional field '(NXmonochromator)' was added to NXbeam_path.

domna · 2022-07-26T13:38:18Z

optical_spectroscopy/luminescence/NXluminescence.yaml

@@ -505,3 +520,4 @@ symbols:
        doc: "We recommend to use wavelength as a default attribute, but it can be
              replaced by any suitable parameter along the X-axis."
    # How to record excitation spectrum?
+    # Possibility for Maps and Linescans, i.e. additional navigation axes


I think this is a general question I already raised for other appdefs: how do we represent arbitrary scan parameters in a clear manner?

domna · 2022-07-26T13:41:13Z

optical_spectroscopy/luminescence/NXluminescence.yaml

@@ -237,6 +251,7 @@ symbols:
            enumeration: [PMT, photodiode, avalanche diode, CCD camera,
                          CCD spectrometer, bolometer, other]
          # x-ray detector?
+          # streak camera for time-resolved measurements?


This could also be represented as a CCD camera as the detector and a MCT + electron tube + phosphorescence screen in the beam_path. But maybe this is too complicated?

Sounds a bit complicated, usually the "streak camera" as a whole system is seen as a detector, I would say.

domna

Thank you for the nice starting point.

I think my comments boil down to the following general considerations:

How do we represent an optical beam path as general as possible? Do we want to use NXtransformations to define the relations between the elements?
How can we support general scanning parameters in the appdef without getting to specific, because I think there are many people coming up with different scan parameters, e.g. space, time, temperature, angle, excitation wavelength, detection wavelength etc.

I think if we solve this questions the appdef can nicely also account for many other optical experiments, since I think they all have a very similar structure (i.e. transmission, reflection, luminescence, Raman, hyper spectral imaging, PLE, TRPL, maybe also ultrashort methods like THz-TDS, Pump-Probe, Four-Wave-Mixing - but there we would also need to represent scanning stages for time delay and different detection methods such as EOS).

jlaehne · 2022-07-26T14:43:00Z

After having another look, I think the most consistent way of defining the beam paths is to include the 'excitation source' / 'detector', as well as 'spectrometer' just as additional optical elements in the beam paths and not on a higher hierarchy level.

Edit: Though, power source or electron source do not have an optical beam_path in the excitation, which would be an argument to keep the source separate.

cmmngr · 2022-08-05T07:37:19Z

optical_spectroscopy/luminescence/NXluminescence.yaml


        type:
          doc: "Type of excitation source."
          enumeration: [laser, lamp, X-rays, silicon carbide globar,
            super continuum, chemical reaction, ultrasound, living organism,
            other]
+        # 'electron beam' - in that case, to really track all relevant metadata, probably the corresponding 
+        # NXclass for a scanning or transmission electron microscope would need to be used, see below


'electron source' added

cmmngr · 2022-08-05T07:37:36Z

optical_spectroscopy/luminescence/NXluminescence.yaml


      excitation(NXsubentry):
        doc: "Properties of the excitation source. The user has to define at
          least one of the excitation sources, i.e. at least one of the
          subclasses describing various sources has to be filled out. 
          The beam path between the excitation source and the sample should be
          described in beam_path_before."
+      # 'beam_path_excitation' instead of 'beam_path_before'?


changed to 'beam_path_excitation'

Then the other part is not after but emission. Actually both changes make sense.

cmmngr · 2022-08-05T07:42:06Z

optical_spectroscopy/luminescence/NXluminescence.yaml

@@ -212,13 +223,16 @@ symbols:
              element/monochromator, and a detector. Describe the beam path 
              between the sample and the detection unit in beam_path_after."

+        # 'beam_path_detection' instead of 'beam_path_after'?


changed to 'beam_path_detection'

well, as noted above: or emission.

cmmngr · 2022-08-05T07:44:40Z

optical_spectroscopy/luminescence/NXluminescence.yaml

        beam_path_after(NXbeam_path):
          exists: optional
          doc: "Description of the beam path between the sample and the
            detector unit ('after' the sample). Describe all relevant optical
            elements and their parameters in the appropriate subclasses."

-        spectrometer(NXdetector):
+        spectrometer(NXdetector): # NXmonochromomator? The detector is the CCD, PMT, StreakCamera, ...


changed to 'spectrometer(NXmonochromator)'

cmmngr · 2022-08-05T07:52:38Z

optical_spectroscopy/luminescence/NXluminescence.yaml

+          doc: "Source for cathodoluminescence. Describe the experimental
+                conditions under which the electron microscope is operated."
+        # sort sources alphabetically?
+


NXem is an application definition. Couldn't find NXem_nion...

Comments on NXluminescence.yaml

6273fcd

This PR serves to comment on the current version of the NXluminescence proposal. (to be continued).

domna reviewed Jul 26, 2022

View reviewed changes

jlaehne added 2 commits July 26, 2022 16:15

Comments on NXbeam_path.yaml

0bcbdf4

Update NXluminescence.yaml

87e9253

cmmngr self-assigned this Jul 27, 2022

cmmngr reviewed Aug 5, 2022

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comments on NXluminescence.yaml #36

Comments on NXluminescence.yaml #36

jlaehne commented Jul 22, 2022

domna Jul 26, 2022

jlaehne Jul 26, 2022

tomio13 Sep 19, 2022

domna Jul 26, 2022

tomio13 Sep 19, 2022

domna Jul 26, 2022

domna Jul 26, 2022

jlaehne Jul 26, 2022

cmmngr Aug 5, 2022

domna Jul 26, 2022

domna Jul 26, 2022

jlaehne Jul 26, 2022

domna left a comment

jlaehne commented Jul 26, 2022 •

edited

Loading

cmmngr Aug 5, 2022

cmmngr Aug 5, 2022

tomio13 Aug 5, 2022

cmmngr Aug 5, 2022

tomio13 Aug 5, 2022

cmmngr Aug 5, 2022

cmmngr Aug 5, 2022

Comments on NXluminescence.yaml #36

Are you sure you want to change the base?

Comments on NXluminescence.yaml #36

Conversation

jlaehne commented Jul 22, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domna left a comment

Choose a reason for hiding this comment

jlaehne commented Jul 26, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jlaehne commented Jul 26, 2022 •

edited

Loading