Add first NXraman Version#1375
Closed
RonHildebrandt wants to merge 658 commits intonexusformat:mainfrom
Closed
Conversation
Start discussing XRD application definition
minor error.
…documentation, adding first round of changes relevant for the implementation of the refactoring of the em-related readers in pynxtools
…sical-quantities-glossary
…age of more general base classes NXserialized, NXidentifier, and CG base classes, also incorporate feedback from discussions with Cameca and generally allow that NXapm can store different state of LEAP-based analyses, reorganizing constraints is another reason for NXapm refactoring, ii) make the currently paraprobe-specific base classes more generally applicable: an example currently NXapm_paraprobe_nanochem allowed to store only the specific way how delocalization based analyses work and what they mean and generate when using paraprobe, but ideally we would like to use a base class NXdelocalization also store delocalizations done with other tools (foremost) those by cameca to arrive at a suggestion for a description format whereby users can store serialized analysis results from atom probe on zenodo in a pre-harmonized way despite not having an appdef designed for it yet, iii) reduce redundancies and make descriptions like for the em refactoring more succinct
…n a minimum example, next steps i) apply to paraprobe_ranger, ii) refactor NXapm appdef, iii) update pynxtools, iv) discuss
…s in the catchen test
…gestions and reviews and feedback from community should target NXem first before thinking about offsprings
Cleanly removed NXem_base class
EM refactoring / EMv2
* Pin nyaml==0.0.8 * Regenerate nxdls
…in-nxsource Remove unneeded fields in NXsource
* Add nexus definitions/files for beam path description * Update base_classes/nyaml/NXopt_assembly.yaml Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Update base_classes/nyaml/NXopt_assembly.yaml Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * add_NX_defs_for_beam_path * modifying_yaml_files * fixing_nyaml_make_file * Adjusted files with Sandor together according to earlier hardcoded .nxs file * Added the missing nxdl.xml files via nyaml2nxdl Version=0.0.8 was used for nyaml. * moved created nxdl.xml files to correct directory * Suggestions to fix ci/cd by in NXtransfer_matrix_table.yaml Co-authored-by: Florian Dobener <github@schroedingerscat.org> * renaming transfer_matrix_table to beam_transfermatrix_table and opt_element to beam_device; also merging NXopt_beam to NXbeam * remove old nxdl files --------- Co-authored-by: Ron Hildebrandt <RonHildebrandt@uni-leipzig.de> Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Co-authored-by: Florian Dobener <github@schroedingerscat.org>
* replace block dimensions * pinning lxml, because old versions fail
Contributor
Author
|
Sorry for this mistake - wrong base was selected in creation of the draft |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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)".
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