From ffc719677c5199270264c381e9bebe4bd65035c3 Mon Sep 17 00:00:00 2001 From: Ron <139139971+RonHildebrandt@users.noreply.github.com> Date: Wed, 6 Mar 2024 12:51:36 +0100 Subject: [PATCH] Add nexus definitions/files for beam path description (#183) * 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 * 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 Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Co-authored-by: Florian Dobener --- base_classes/NXbeam.nxdl.xml | 23 +++- base_classes/nyaml/NXbeam.yaml | 8 +- .../NXbeam_device.nxdl.xml | 67 ++++++++++ .../NXbeam_transfer_matrix_table.nxdl.xml | 120 ++++++++++++++++++ .../nyaml/NXbeam_device.yaml | 41 ++++++ .../nyaml/NXbeam_transfer_matrix_table.yaml | 85 +++++++++++++ nyaml.mk | 2 +- 7 files changed, 338 insertions(+), 8 deletions(-) create mode 100644 contributed_definitions/NXbeam_device.nxdl.xml create mode 100644 contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXbeam_device.yaml create mode 100644 contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index 9bf36c06be..67c6dc4b26 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -1,10 +1,10 @@ - + + + + Properties of generic beam device in an experimental setup. + + Any beam related devices like source, detector, filter, mirror, + beamsplitter, ... which may modifies a beam in an experimental setup + can be described here with its experimental position and relationship + to the other beam devices in the setup. + + + + Single device or list of devices pointing to the devices from which an + beam originated to reach this device. + This is used to describe a logical order of devices and for the whole setup. + In this way, a "beam path" can be described (i.e., with starting point (light source) + and end point (photo detector)). + + Example: /entry/instrument/detector. + + + + + Description of the intended purpose of this device for + the experimental setup. + + + + + Name of the group with which this device can be associated. + For example, if a group of devices is used for second harmonic generation, + all these devices have the group name "second harmonic generation". + Is used for simplified setup vizualization (or description?). + + + + + Location and orientation of the device. Note that even a + simple distance can be given as a translation. + + You can use the @depends_on to describe from which device + the transformation needs to be applied. + + + diff --git a/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml b/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml new file mode 100644 index 0000000000..570ac74dbd --- /dev/null +++ b/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml @@ -0,0 +1,120 @@ + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Length of the array associated to the data type. + + + + + Contains datastructures of an experimental optical setup (i.e., multiple + transfermatrix tables). These datastructures are used to relate physical + properties of two beams (NXbeam) which have one common optical element + (NXopt_element) (one specific transfermatrix). + One of these beams in an input beam and the other one is an output beam. + + The data describes the change of beam properties, e.g. the intensity of a + beam is reduced because the transmission coefficient of the beam device is + lower than 1. + + + + Select which type of data was recorded, for example aperture and + focal length. + It is possible to have multiple selections. This selection defines + how many columns (N_variables) are stored in the data array. + N in the name, is the index number in which order the given + property is listed. + + + + + + + + + + + Please list in this array the column and row names used in your actual data. + That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] + and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix + ['JM1','JM2'] + + + + + + + + Contains the datastructure which relates beam properties of an + input and output beam as result of the input beam interaction + with the beam device. + + Transfermatrix relationship between N input beams and M output beams. + It contains a table with the relevant matricis to be used for different + transmissitted properties (such as polarization, intensity, phase). + + Data structure for all transfermatrices of an beam device in a setup. + For each combination of N input and M output beams and for L physical + concept (i.e. beam intensity), one matrix can be defined. + + In this way, the transfermatrix table has the dimension NxM. + + For each entry, in this transfermatrix, there are L formalisms. + Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, + whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). + + A beamsplitter with two input laser beams can have a total of + four transfermatrices (2 Input x 2 Output). + + The dimension of the transfermatrix depends on the parameters. + Examples are: + 1x1 for intensity/power + 2x2 for jones formalism + 3x3 for direction + + + + Specific name of input beam which the transfermatrix table is related to. + + + + + Specific name of output beam which the transfermatrix table is related to. + + + + + Square matrix with dimension N_variables x N_variables + + + + + + diff --git a/contributed_definitions/nyaml/NXbeam_device.yaml b/contributed_definitions/nyaml/NXbeam_device.yaml new file mode 100644 index 0000000000..3af998a41e --- /dev/null +++ b/contributed_definitions/nyaml/NXbeam_device.yaml @@ -0,0 +1,41 @@ +category: base +doc: | + Properties of generic beam device in an experimental setup. + + Any beam related devices like source, detector, filter, mirror, + beamsplitter, ... which may modifies a beam in an experimental setup + can be described here with its experimental position and relationship + to the other beam devices in the setup. + + +NXbeam_device(NXobject): + + previous_devices: + doc: | + Single device or list of devices pointing to the devices from which an + beam originated to reach this device. + This is used to describe a logical order of devices and for the whole setup. + In this way, a "beam path" can be described (i.e., with starting point (light source) + and end point (photo detector)). + + Example: /entry/instrument/detector. + purpose(NX_CHAR): + doc: | + Description of the intended purpose of this device for + the experimental setup. + + group(NX_CHAR): + doc: | + Name of the group with which this device can be associated. + For example, if a group of devices is used for second harmonic generation, + all these devices have the group name "second harmonic generation". + Is used for simplified setup vizualization (or description?). + + + (NXtransformations): + doc: | + Location and orientation of the device. Note that even a + simple distance can be given as a translation. + + You can use the @depends_on to describe from which device + the transformation needs to be applied. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml b/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml new file mode 100644 index 0000000000..60df03907c --- /dev/null +++ b/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml @@ -0,0 +1,85 @@ +category: base +doc: | + Contains datastructures of an experimental optical setup (i.e., multiple + transfermatrix tables). These datastructures are used to relate physical + properties of two beams (NXbeam) which have one common optical element + (NXopt_element) (one specific transfermatrix). + One of these beams in an input beam and the other one is an output beam. + + The data describes the change of beam properties, e.g. the intensity of a + beam is reduced because the transmission coefficient of the beam device is + lower than 1. +symbols: + doc: | + Variables used throughout the document, e.g. dimensions or parameters. + N_variables: | + Length of the array associated to the data type. +NXbeam_transfer_matrix_table(NXobject): + datatype_N: + doc: | + Select which type of data was recorded, for example aperture and + focal length. + It is possible to have multiple selections. This selection defines + how many columns (N_variables) are stored in the data array. + N in the name, is the index number in which order the given + property is listed. + enumeration: + [ + aperture, + focallength, + orientation, + jones matrix, + ] + matrix_elements: + doc: | + Please list in this array the column and row names used in your actual data. + That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] + and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix + ['JM1','JM2'] + dimensions: + rank: 1 + dim: [[1, N_variables]] + + TRANSFER_MATRIX(NX_NUMBER): + doc: | + Contains the datastructure which relates beam properties of an + input and output beam as result of the input beam interaction + with the beam device. + + Transfermatrix relationship between N input beams and M output beams. + It contains a table with the relevant matricis to be used for different + transmissitted properties (such as polarization, intensity, phase). + + Data structure for all transfermatrices of an beam device in a setup. + For each combination of N input and M output beams and for L physical + concept (i.e. beam intensity), one matrix can be defined. + + In this way, the transfermatrix table has the dimension NxM. + + For each entry, in this transfermatrix, there are L formalisms. + Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, + whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). + + A beamsplitter with two input laser beams can have a total of + four transfermatrices (2 Input x 2 Output). + + The dimension of the transfermatrix depends on the parameters. + Examples are: + 1x1 for intensity/power + 2x2 for jones formalism + 3x3 for direction + \@input: + doc: | + Specific name of input beam which the transfermatrix table is related to. + \@output: + doc: | + Specific name of output beam which the transfermatrix table is related to. + dimensions: + doc: | + Square matrix with dimension N_variables x N_variables + rank: 2 + dim: + [ + [1, N_variables], + [2, N_variables], + ] \ No newline at end of file diff --git a/nyaml.mk b/nyaml.mk index 5a475dedb6..898ebd6cc5 100644 --- a/nyaml.mk +++ b/nyaml.mk @@ -22,4 +22,4 @@ $(APPDEF_DIR)/$(NYAML_SUBDIR)/%.yaml : $(APPDEF_DIR)/%.nxdl.xml nyaml: $(NXDL_BC_TARGETS) $(NXDL_APPDEF_TARGETS) $(NXDL_CONTRIB_TARGETS) -all: nyaml \ No newline at end of file +all: nyaml