-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add first NXraman Version #201
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While going through this I thought it might be helpful to group the beam_devices together in one sub-group. Then it might be easier to understand how they belong together.
company: | ||
exists: optional | ||
doc: | | ||
Name of the company which build the instrument. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we have NXfabrication
to denote manufacturar information (or NXmanufacturer... I don't fully recall rn).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good. I've replaced it with that.
enumeration: [in situ Raman spectroscopy, resonant Raman spectroscopy, non-resonant Raman spectroscopy, Raman imaging, Tip-enhanced Raman spectroscopy (TERS), Surface-enhanced Raman spectroscopy (SERS), Surface plasmon polariton enhanced Raman scattering (SPPERS), Hyper Raman spectroscopy (HRS), Stimulated Raman spectroscopy (SRS), Inverse Raman spectroscopy (IRS), Coherent anti-Stokes Raman spectroscopy (CARS)] | ||
(NXinstrument): | ||
doc: | | ||
Properties of the Instruments used for Raman instrumeasurements. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Properties of the Instruments used for Raman instrumeasurements. | |
Properties of the instruments used for Raman measurements. |
Maybe not properties but rather metadata or so?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ive addressed this
experiment_type: | ||
doc: | | ||
Specify the type of Raman measurement. | ||
enumeration: [in situ Raman spectroscopy, resonant Raman spectroscopy, non-resonant Raman spectroscopy, Raman imaging, Tip-enhanced Raman spectroscopy (TERS), Surface-enhanced Raman spectroscopy (SERS), Surface plasmon polariton enhanced Raman scattering (SPPERS), Hyper Raman spectroscopy (HRS), Stimulated Raman spectroscopy (SRS), Inverse Raman spectroscopy (IRS), Coherent anti-Stokes Raman spectroscopy (CARS)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe also allow for an other field?
In mpes we came up with a bunch of enumerations, too and it was almost always requested to also have an additional free-text input for everything not fitting to the list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All right, ive added this with addition to specify the option "other" by another field
doc: | | ||
ISO8601 date when the instrument was constructed. | ||
UTC offset should be specified. | ||
software(NXprocess): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should not be an NXprocess
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahhh okay :D I just copied it from NXellipsometry. Thaught this was okay. In principle up to now, it should be a free text to enter some information?
exists: optional | ||
doc: | | ||
Name of the company which build the instrument. | ||
construction_year(NX_DATE_TIME): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should also belong into NXfabrication
doc: | | ||
beam device instance of the optical source. | ||
device: | ||
doc: | | ||
It should contain the name of the Nexus source group. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The docstring read a bit as work in progress?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adjusted this and as well restructured the order of NXbeam_device and other NeXus derived optical elements
doc: | | ||
Monochromator with arbitrary choice of the name, which shall be referenced | ||
by the spectrometer(NXbeam_device). | ||
Sample_as_beam_element(NXbeam_device): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sample_as_beam_element(NXbeam_device): | |
sample_as_beam_element(NXbeam_device): |
I think it's a typo or is it meant to also contain names like bananample_as_beam_element
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea - this sounds good. Maybe in a future project we will need this :x (yea its a typo)
device: | ||
doc: | | ||
Contains the link to the sample. | ||
(NXsample): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to require a name or molecular formula of the sample or at least recommend them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah okay. Ive added some exists: with required and recommended.
data_collection(NXprocess): | ||
data_type: | ||
doc: | | ||
Select which type of data was recorded, for example a simple spectrum | ||
with intensity vs. Raman shift, CCD image or a set of spectra with | ||
probe, reference and background signals for pump beam on and off. | ||
enumeration: [Integrated single spectrum, CCD image, Probe + Background + Reference for Pump-on and Pump-off (i.e. for FSRS)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this part. NXprocess
is intended to describe post-processing of data. Here it's just used to denote which typo of data was collected. For me this rather belongs into the (NXdetector) group or so
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is defined in this way in NXopt. Maybe thats a remaining thing from the Harmonization of NXellipsometry and NXopt?
Right, from the definition of NXprocess, this does not seem to be proper.
No action done yet - have to discuss this.
@@ -31,6 +34,10 @@ NXbeam_device(NXobject): | |||
all these devices have the group name "second harmonic generation". | |||
Is used for simplified setup vizualization (or description?). | |||
|
|||
device: | |||
doc: | | |||
This is the name of the NeXus device like a NXdetector, a NXmonochromator or NXsource. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider making this a link, i.e., a reference to a full path of data entry. Something like /entry/instrument/monochromator
. Then it's clear to which detector this refers,
see here for an example
Ive just ordered the beam_devices and not put them in a subgroup, as they are supposed to be on directly below the instrument level. Thanks for advice, Ive considered almost all of them and will commit them soon. |
I like to close this PR, as this will be implemented in PR220 (#220) |
I want to implement the first NeXus definition for NXraman.
As the latest version of NXellipsometry is derived from NXopt, the NXraman here is as well derived from NXopt.
Therefore, the Version here used "NXbeam_path", which will be replaced in the future by using "NXbeam_device" via "previous_devices". This was motivated by the fact, that there is right now no "NXlens_opt(NXbeam_device)" or "NXdetector(NXbeam_device)" [see Issue #202]
What is necessary?
From a physical point of view, these are the most important things for a Raman scattering experiment:
Beyond this, there are many nice to have parameters, but from my point of view not necessary to be able to use this spectrum.
Questions:
A) No symbols were used here, as these were not used in the original NXellipsometry(NXopt) definition. It this fine that way, or at which pointare these symbols used?
B) Is the "scattering_configuration" implemented fine this way? Usually, the "Porto notation" is enough to describe the experiment and beatiful simple. But, it can be the case, that you want to give the specific vectors instead of x,y,z. I just wanted to do this as List of 4 Vectors with dimension 3. Is this okay?
C) Depending on the NXbeam_path or NXbeam_device approach, I may have to completely redo this PR. What is the strategy?
TL;DR: Created NXraman.yaml file similar to NXellipsometry.yaml