From 2b1f23cd64a4d382693fcfe69e5540d61a35f9ad Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 9 Aug 2023 18:06:05 +0200 Subject: [PATCH 01/14] Readds base classes for mpes (from commit 843283a) # Conflicts: # base_classes/NXaperture.nxdl.xml --- base_classes/NXbeam.nxdl.xml | 141 ++++++++++++++++++++++++++++- base_classes/NXinstrument.nxdl.xml | 25 +++++ base_classes/NXprocess.nxdl.xml | 15 +++ 3 files changed, 178 insertions(+), 3 deletions(-) diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index b3a44a1db..a2f2ecda5 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -61,11 +61,45 @@ Distance from sample. Note, it is recommended to use NXtransformations instead. - Energy carried by each particle of the beam on entering the beamline component + + Energy carried by each particle of the beam on entering the beamline component. + + In the case of a monochromatic beam this is the scalar energy. + Several other use cases are permitted, depending on the + presence of other incident_energy_X fields. + + * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. + * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. + Here, incident_energy_weights and incident_energy_spread are not set. + * In the case of a polychromatic beam that varies shot-to-shot, + this is an array of length m with the relative weights in incident_energy_weights as a 2D array. + * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, + this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. + + Note, variants are a good way to represent several of these use cases in a single dataset, + e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. + + + + The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in + the energy spread, this is a 2D array of dimension nP by m + (slow to fast) of the spreads of the corresponding + wavelength in incident_wavelength. + + + + + In the case of a polychromatic beam this is an array of length m of the relative + weights of the corresponding energies in incident_energy. In the case of a + polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np + by m (slow to fast) of the relative weights of the corresponding energies in + incident_energy. + + Energy carried by each particle of the beam on leaving the beamline component @@ -174,18 +208,59 @@ - Polarization vector on entering beamline component + + Incident polarization as a Stokes vector + on entering beamline component + + + + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. + + - Polarization vector on leaving beamline component + + Polarization as Stokes vector on leaving beamline component + + + + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. + + @@ -245,6 +320,66 @@ + + + Energy of a single pulse at the diagnostic point + + + + + Average power at the diagnostic point + + + + + Incident fluence at the diagnostic point + + + + Here: SI units are 'J/m2', customary 'mJ/cm2'. + + + + + + FWHM duration of the pulses at the diagnostic point + + + + + FROG trace of the pulse. + + + + + + + + + Horizontal axis of a FROG trace, i.e. delay. + + + + + + + + Vertical axis of a FROG trace, i.e. frequency. + + + + + + + + The type of chirp implemented + + + + + Group delay dispersion of the pulse for linear chirp + + Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index 15e764540..c357d7b7f 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -42,6 +42,31 @@ short name for instrument, perhaps the acronym + + + Energy resolution of the experiment (FWHM or gaussian broadening) + + + + + Momentum resolution of the experiment (FWHM) + + + + + Angular resolution of the experiment (FWHM) + + + + + Spatial resolution of the experiment (Airy disk radius) + + + + + Temporal resolution of the experiment (FWHM) + + diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index d7d1a80f8..65b16c169 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -43,6 +43,21 @@ Date and time of processing. + + + Describes the operations of image registration + + + + + Describes the operations of image distortion correction + + + + + Describes the operations of calibration procedures, e.g. axis calibrations. + + The note will contain information about how the data was processed From 79dc992d0ca0d022ab25f0ce2caebae4413e428e Mon Sep 17 00:00:00 2001 From: Rubel Date: Thu, 24 Aug 2023 15:02:08 +0200 Subject: [PATCH 02/14] Regeneration of the nexus file for fixing the changes coming from old version of yaml. Removing unintensional comments # Conflicts: # base_classes/NXbeam.nxdl.xml # base_classes/NXdetector.nxdl.xml # base_classes/NXentry.nxdl.xml # base_classes/NXinstrument.nxdl.xml # base_classes/NXprocess.nxdl.xml # base_classes/NXsample.nxdl.xml # base_classes/NXsource.nxdl.xml # contributed_definitions/NXcollectioncolumn.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml --- base_classes/NXbeam.nxdl.xml | 141 +---------------------------- base_classes/NXinstrument.nxdl.xml | 25 ----- base_classes/NXprocess.nxdl.xml | 91 ++++++++++--------- 3 files changed, 50 insertions(+), 207 deletions(-) diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index a2f2ecda5..b3a44a1db 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -61,45 +61,11 @@ Distance from sample. Note, it is recommended to use NXtransformations instead. - - Energy carried by each particle of the beam on entering the beamline component. - - In the case of a monochromatic beam this is the scalar energy. - Several other use cases are permitted, depending on the - presence of other incident_energy_X fields. - - * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. - * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. - Here, incident_energy_weights and incident_energy_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_energy_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. - + Energy carried by each particle of the beam on entering the beamline component - - - The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in - the energy spread, this is a 2D array of dimension nP by m - (slow to fast) of the spreads of the corresponding - wavelength in incident_wavelength. - - - - - In the case of a polychromatic beam this is an array of length m of the relative - weights of the corresponding energies in incident_energy. In the case of a - polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np - by m (slow to fast) of the relative weights of the corresponding energies in - incident_energy. - - Energy carried by each particle of the beam on leaving the beamline component @@ -208,59 +174,18 @@ - - Incident polarization as a Stokes vector - on entering beamline component - + Polarization vector on entering beamline component - - - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. - - - - Polarization as Stokes vector on leaving beamline component - + Polarization vector on leaving beamline component - - - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. - - @@ -320,66 +245,6 @@ - - - Energy of a single pulse at the diagnostic point - - - - - Average power at the diagnostic point - - - - - Incident fluence at the diagnostic point - - - - Here: SI units are 'J/m2', customary 'mJ/cm2'. - - - - - - FWHM duration of the pulses at the diagnostic point - - - - - FROG trace of the pulse. - - - - - - - - - Horizontal axis of a FROG trace, i.e. delay. - - - - - - - - Vertical axis of a FROG trace, i.e. frequency. - - - - - - - - The type of chirp implemented - - - - - Group delay dispersion of the pulse for linear chirp - - Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index c357d7b7f..15e764540 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -42,31 +42,6 @@ short name for instrument, perhaps the acronym - - - Energy resolution of the experiment (FWHM or gaussian broadening) - - - - - Momentum resolution of the experiment (FWHM) - - - - - Angular resolution of the experiment (FWHM) - - - - - Spatial resolution of the experiment (Airy disk radius) - - - - - Temporal resolution of the experiment (FWHM) - - diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index 65b16c169..ac5a8b81d 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -1,9 +1,9 @@ - + - - Document an event of data processing, reconstruction, or analysis for this data. + + + Document an event of data processing, reconstruction, or analysis for this data. + - Name of the program used + + Name of the program used + - Sequence index of processing, - for determining the order of multiple **NXprocess** steps. - Starts with 1. + Sequence index of processing, + for determining the order of multiple **NXprocess** steps. + Starts with 1. - Version of the program used + + Version of the program used + - Date and time of processing. + + Date and time of processing. + - - Describes the operations of image registration - - - - - Describes the operations of image distortion correction - - - - - Describes the operations of calibration procedures, e.g. axis calibrations. - - + + Describes the operations of image registration + + + + + Describes the operations of image distortion correction + + + + + Describes the operations of calibration procedures, e.g. axis calibrations. + + - The note will contain information about how the data was processed - or anything about the data provenance. - The contents of the note can be anything that the processing code - can understand, or simple text. - - The name will be numbered to allow for ordering of steps. + The note will contain information about how the data was processed + or anything about the data provenance. + The contents of the note can be anything that the processing code + can understand, or simple text. + + The name will be numbered to allow for ordering of steps. - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - From 99b2d0d0f79ea42e15a2c91ee0d656023a5b1f28 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 16 Sep 2024 15:48:12 +0200 Subject: [PATCH 03/14] format base classes and applications in accordance to existing NIAC version # Conflicts: # applications/NXarpes.nxdl.xml # applications/nyaml/NXarpes.yaml # base_classes/NXaperture.nxdl.xml # base_classes/NXbeam.nxdl.xml # base_classes/NXdata.nxdl.xml # base_classes/NXdetector.nxdl.xml # base_classes/NXentry.nxdl.xml # base_classes/NXenvironment.nxdl.xml # base_classes/NXinstrument.nxdl.xml # base_classes/NXmonochromator.nxdl.xml # base_classes/NXroot.nxdl.xml # base_classes/NXsample.nxdl.xml # base_classes/NXsample_component.nxdl.xml # base_classes/NXsensor.nxdl.xml # base_classes/NXsource.nxdl.xml # base_classes/NXsubentry.nxdl.xml # base_classes/NXtransformations.nxdl.xml # base_classes/NXuser.nxdl.xml # base_classes/nyaml/NXaperture.yaml # base_classes/nyaml/NXbeam.yaml # base_classes/nyaml/NXdata.yaml # base_classes/nyaml/NXdetector.yaml # base_classes/nyaml/NXentry.yaml # base_classes/nyaml/NXenvironment.yaml # base_classes/nyaml/NXinstrument.yaml # base_classes/nyaml/NXmonochromator.yaml # base_classes/nyaml/NXprocess.yaml # base_classes/nyaml/NXroot.yaml # base_classes/nyaml/NXsample.yaml # base_classes/nyaml/NXsample_component.yaml # base_classes/nyaml/NXsensor.yaml # base_classes/nyaml/NXsource.yaml # base_classes/nyaml/NXsubentry.yaml # base_classes/nyaml/NXtransformations.yaml # base_classes/nyaml/NXuser.yaml --- Makefile | 21 ++---------- base_classes/NXprocess.nxdl.xml | 60 +++++++++++++++------------------ 2 files changed, 30 insertions(+), 51 deletions(-) diff --git a/Makefile b/Makefile index 3a882c256..e1d0696fa 100644 --- a/Makefile +++ b/Makefile @@ -60,9 +60,6 @@ test :: clean :: $(RM) -rf $(BUILD_DIR) - $(RM) -rf $(BASE_CLASS_DIR)/$(NYAML_SUBDIR) - $(RM) -rf $(APPDEF_DIR)/$(NYAML_SUBDIR) - $(RM) -rf $(CONTRIB_DIR)/$(NYAML_SUBDIR) prepare :: $(PYTHON) -m dev_tools manual --prepare --build-root $(BUILD_DIR) @@ -97,24 +94,10 @@ all :: @echo "HTML built: `ls -lAFgh $(BUILD_DIR)/manual/build/html/index.html`" @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/manual/build/latex/nexus.pdf`" -$(BASE_CLASS_DIR)/%.nxdl.xml : $(BASE_CLASS_DIR)/$(NYAML_SUBDIR)/%.yaml - nyaml2nxdl $< --output-file $@ - -$(CONTRIB_DIR)/%.nxdl.xml : $(CONTRIB_DIR)/$(NYAML_SUBDIR)/%.yaml - nyaml2nxdl $< --output-file $@ - -$(APPDEF_DIR)/%.nxdl.xml : $(APPDEF_DIR)/$(NYAML_SUBDIR)/%.yaml - nyaml2nxdl $< --output-file $@ - -nxdl: $(YBC_NXDL_TARGETS) $(YCONTRIB_NXDL_TARGETS) $(YAPPDEF_NXDL_TARGETS) - -nyaml: - $(MAKE) -f nyaml.mk - # NeXus - Neutron and X-ray Common Data Format # -# Copyright (C) 2008-2024 NeXus International Advisory Committee (NIAC) +# Copyright (C) 2008-2022 NeXus International Advisory Committee (NIAC) # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public @@ -130,4 +113,4 @@ nyaml: # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # -# For further information, see http://www.nexusformat.org +# For further information, see http://www.nexusformat.org \ No newline at end of file diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index ac5a8b81d..c389367ea 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -1,5 +1,5 @@ - + - - - Document an event of data processing, reconstruction, or analysis for this data. - + + Document an event of data processing, reconstruction, or analysis for this data. - - Name of the program used - + Name of the program used - Sequence index of processing, - for determining the order of multiple **NXprocess** steps. - Starts with 1. + Sequence index of processing, + for determining the order of multiple **NXprocess** steps. + Starts with 1. - - Version of the program used - + Version of the program used - - Date and time of processing. - + Date and time of processing. @@ -64,25 +60,25 @@ - The note will contain information about how the data was processed - or anything about the data provenance. - The contents of the note can be anything that the processing code - can understand, or simple text. - - The name will be numbered to allow for ordering of steps. + The note will contain information about how the data was processed + or anything about the data provenance. + The contents of the note can be anything that the processing code + can understand, or simple text. + + The name will be numbered to allow for ordering of steps. - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. From dcf3fb530bd8f379366914d7838e0392b6ff6e62 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 23 Sep 2024 17:22:03 +0200 Subject: [PATCH 04/14] revert unintentional changes from cherry-pick fix copyright dates --- Makefile | 21 +++++++++++++++++++-- base_classes/NXprocess.nxdl.xml | 2 +- 2 files changed, 20 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index e1d0696fa..3a882c256 100644 --- a/Makefile +++ b/Makefile @@ -60,6 +60,9 @@ test :: clean :: $(RM) -rf $(BUILD_DIR) + $(RM) -rf $(BASE_CLASS_DIR)/$(NYAML_SUBDIR) + $(RM) -rf $(APPDEF_DIR)/$(NYAML_SUBDIR) + $(RM) -rf $(CONTRIB_DIR)/$(NYAML_SUBDIR) prepare :: $(PYTHON) -m dev_tools manual --prepare --build-root $(BUILD_DIR) @@ -94,10 +97,24 @@ all :: @echo "HTML built: `ls -lAFgh $(BUILD_DIR)/manual/build/html/index.html`" @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/manual/build/latex/nexus.pdf`" +$(BASE_CLASS_DIR)/%.nxdl.xml : $(BASE_CLASS_DIR)/$(NYAML_SUBDIR)/%.yaml + nyaml2nxdl $< --output-file $@ + +$(CONTRIB_DIR)/%.nxdl.xml : $(CONTRIB_DIR)/$(NYAML_SUBDIR)/%.yaml + nyaml2nxdl $< --output-file $@ + +$(APPDEF_DIR)/%.nxdl.xml : $(APPDEF_DIR)/$(NYAML_SUBDIR)/%.yaml + nyaml2nxdl $< --output-file $@ + +nxdl: $(YBC_NXDL_TARGETS) $(YCONTRIB_NXDL_TARGETS) $(YAPPDEF_NXDL_TARGETS) + +nyaml: + $(MAKE) -f nyaml.mk + # NeXus - Neutron and X-ray Common Data Format # -# Copyright (C) 2008-2022 NeXus International Advisory Committee (NIAC) +# Copyright (C) 2008-2024 NeXus International Advisory Committee (NIAC) # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public @@ -113,4 +130,4 @@ all :: # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # -# For further information, see http://www.nexusformat.org \ No newline at end of file +# For further information, see http://www.nexusformat.org diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index c389367ea..7a9cecd4d 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + A description of the procedures employed. + + + + + The physical quantity of the calibration, e.g., + energy, momentum, time, etc. + + + + + A digital persistent identifier (e.g., DOI, ISO standard) referring to a detailed description of a + calibration method but no actual calibration data. + + + + + A digital persistent identifier (e.g., a DOI) referring to a publicly available calibration measurement + used for this instrument, e.g., a measurement of a known standard containing calibration information. + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + + + + A file serialisation of a calibration which may not be publicly available (externally from the nexus file). + + This metadata can be a documentation of the source (file) or database (entry) from which pieces + of information have been extracted for consumption (e.g. in a research data management system (RDMS)). + It is also possible to include the actual file by using the `file` field. + + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + Name of the software used for this calibration. + + + + Software version. + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. + This should comply to the following naming rules (similar to python's naming rules): + + * A variable name must start with a letter or the underscore character + * A variable name cannot start with a number + * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) + * Variable names are case-sensitive (age, Age and AGE are three different variables) + + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + + + + Additional input axis to be used in the formula. + The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., + if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. + + + + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the nth position in the `original_axis` field. + If there is the symbol attribute specified for the `original_axis` this may be used instead of x. + If you want to use the whole axis use `x`. + Alternate axis can also be available as specified by the `input_SYMBOL` field. + The data should then be referred here by the `SYMBOL` name, e.g., for a field + name `input_my_field` it should be referred here by `my_field` or `my_field0` if + you want to read the zeroth element of the array. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + + + + + For linear calibration. Offset parameter. + This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + + + + + Mapping data for calibration. + + This can be used to map data points from uncalibrated to calibrated values, + i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + The path to which this data is written, e.g., the calibrated energy. + Should be a valid NeXus path name, e.g., /entry/data/energy. + + + + + + Any data acquired/used during the calibration that does not fit the `NX_FLOAT` fields above. + NXdata groups can be used for multidimensional data which are relevant to the calibration + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + diff --git a/base_classes/NXdistortion.nxdl.xml b/base_classes/NXdistortion.nxdl.xml new file mode 100644 index 000000000..f1c5054e7 --- /dev/null +++ b/base_classes/NXdistortion.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of symmetry points used for distortion correction + + + + + Number of points of the matrix distortion field (x direction) + + + + + Number of points of the matrix distortion field (y direction) + + + + + Subclass of NXprocess to describe post-processing distortion correction. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the distortion correction been applied? + + + + + For `symmetry-guided distortion correction`_, + where a pattern of features is mapped to the regular geometric structure expected + from the symmetry. Here we record the number of elementary symmetry operations. + + .. _symmetry-guided distortion correction: https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub + + + + + For symmetry-guided distortion correction. Here we record the coordinates of the + symmetry centre point. + + + + + + + + For symmetry-guided distortion correction. Here we record the coordinates of the + relevant symmetry points. + + + + + + + + + Column deformation field for general non-rigid distortion corrections. 2D matrix + holding the column information of the mapping of each original coordinate. + + + + + + + + + Row deformation field for general non-rigid distortion corrections. 2D matrix + holding the row information of the mapping of each original coordinate. + + + + + + + + + Description of the procedures employed. + + + diff --git a/base_classes/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml new file mode 100644 index 000000000..2ae999351 --- /dev/null +++ b/base_classes/NXregistration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Describes image registration procedures. + + + + Has the registration been applied? + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Specifies the position by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + To describe the operations of image registration (combinations of rigid + translations and rotations) + + + + + Description of the procedures employed. + + + From 687734a35a757ca094ee481cf2b425e4a79295ac Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 23 Sep 2024 18:50:51 +0200 Subject: [PATCH 06/14] move base classes to base_classes folder --- .../NXcalibration.nxdl.xml | 111 ------------------ contributed_definitions/NXdistortion.nxdl.xml | 111 ------------------ .../NXregistration.nxdl.xml | 55 --------- 3 files changed, 277 deletions(-) delete mode 100644 contributed_definitions/NXcalibration.nxdl.xml delete mode 100644 contributed_definitions/NXdistortion.nxdl.xml delete mode 100644 contributed_definitions/NXregistration.nxdl.xml diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml deleted file mode 100644 index 8dd7a6da5..000000000 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXdistortion.nxdl.xml b/contributed_definitions/NXdistortion.nxdl.xml deleted file mode 100644 index f1c5054e7..000000000 --- a/contributed_definitions/NXdistortion.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of symmetry points used for distortion correction - - - - - Number of points of the matrix distortion field (x direction) - - - - - Number of points of the matrix distortion field (y direction) - - - - - Subclass of NXprocess to describe post-processing distortion correction. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the distortion correction been applied? - - - - - For `symmetry-guided distortion correction`_, - where a pattern of features is mapped to the regular geometric structure expected - from the symmetry. Here we record the number of elementary symmetry operations. - - .. _symmetry-guided distortion correction: https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub - - - - - For symmetry-guided distortion correction. Here we record the coordinates of the - symmetry centre point. - - - - - - - - For symmetry-guided distortion correction. Here we record the coordinates of the - relevant symmetry points. - - - - - - - - - Column deformation field for general non-rigid distortion corrections. 2D matrix - holding the column information of the mapping of each original coordinate. - - - - - - - - - Row deformation field for general non-rigid distortion corrections. 2D matrix - holding the row information of the mapping of each original coordinate. - - - - - - - - - Description of the procedures employed. - - - diff --git a/contributed_definitions/NXregistration.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml deleted file mode 100644 index 2ae999351..000000000 --- a/contributed_definitions/NXregistration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Describes image registration procedures. - - - - Has the registration been applied? - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Specifies the position by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - To describe the operations of image registration (combinations of rigid - translations and rotations) - - - - - Description of the procedures employed. - - - From 6ad26aad3254d073f407647686bd509b25079e01 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 23 Sep 2024 19:15:49 +0200 Subject: [PATCH 07/14] bring in NXserialized --- base_classes/NXserialized.nxdl.xml | 74 ++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 base_classes/NXserialized.nxdl.xml diff --git a/base_classes/NXserialized.nxdl.xml b/base_classes/NXserialized.nxdl.xml new file mode 100644 index 000000000..fda076948 --- /dev/null +++ b/base_classes/NXserialized.nxdl.xml @@ -0,0 +1,74 @@ + + + + + + Metadata to a set of pieces of information of a resource that has been serialized. + + A typical use case is the documentation of the source (file) or database (entry) + from which pieces of information have been extracted for consumption in e.g. a + research data management system (RDMS). This may be for reasons of enabling + services such as providing access to normalized information for which reading + again from the resource may not be desired, possibe, or feasible. + + Possible reasons could be the extraction of specific information for caching, + performance reasons, or re-evaluate given pieces of information based on other + views and interaction patterns with the data where information has been formatted + differently by tools than how these pieces of information were originally + serialized. + + + + Answers into what resource the information was serialized. + + + + + + + + + Path to the resource. + + E.g. the name of a file or its absolute or relative path, or the + identifier to a resource in another database. + + + + + Value of the hash that is obtained when running algorithm + on the content of the resource referred to by path. + + + + + Name of the algorithm whereby the checksum was computed. + + + + + + Extracted file containing the serialized information. + + + From 838639a982a618d41f2d89b7744ab1379b38351d Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 1 Oct 2024 16:17:07 +0200 Subject: [PATCH 08/14] address NIAC 2024 review comments --- base_classes/NXdistortion.nxdl.xml | 7 +-- base_classes/NXprocess.nxdl.xml | 15 ------ base_classes/NXregistration.nxdl.xml | 5 -- base_classes/NXserialized.nxdl.xml | 74 ---------------------------- 4 files changed, 1 insertion(+), 100 deletions(-) delete mode 100644 base_classes/NXserialized.nxdl.xml diff --git a/base_classes/NXdistortion.nxdl.xml b/base_classes/NXdistortion.nxdl.xml index f1c5054e7..3386e5710 100644 --- a/base_classes/NXdistortion.nxdl.xml +++ b/base_classes/NXdistortion.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays @@ -45,11 +45,6 @@ Subclass of NXprocess to describe post-processing distortion correction. - - - Indicates the name of the last operation applied in the NXprocess sequence. - - Has the distortion correction been applied? diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index 7a9cecd4d..f295bbd6d 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -43,21 +43,6 @@ Date and time of processing. - - - Describes the operations of image registration - - - - - Describes the operations of image distortion correction - - - - - Describes the operations of calibration procedures, e.g. axis calibrations. - - The note will contain information about how the data was processed diff --git a/base_classes/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml index 2ae999351..5499c842b 100644 --- a/base_classes/NXregistration.nxdl.xml +++ b/base_classes/NXregistration.nxdl.xml @@ -30,11 +30,6 @@ Has the registration been applied? - - - Indicates the name of the last operation applied in the NXprocess sequence. - - Specifies the position by pointing to the last transformation in the diff --git a/base_classes/NXserialized.nxdl.xml b/base_classes/NXserialized.nxdl.xml deleted file mode 100644 index fda076948..000000000 --- a/base_classes/NXserialized.nxdl.xml +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - Metadata to a set of pieces of information of a resource that has been serialized. - - A typical use case is the documentation of the source (file) or database (entry) - from which pieces of information have been extracted for consumption in e.g. a - research data management system (RDMS). This may be for reasons of enabling - services such as providing access to normalized information for which reading - again from the resource may not be desired, possibe, or feasible. - - Possible reasons could be the extraction of specific information for caching, - performance reasons, or re-evaluate given pieces of information based on other - views and interaction patterns with the data where information has been formatted - differently by tools than how these pieces of information were originally - serialized. - - - - Answers into what resource the information was serialized. - - - - - - - - - Path to the resource. - - E.g. the name of a file or its absolute or relative path, or the - identifier to a resource in another database. - - - - - Value of the hash that is obtained when running algorithm - on the content of the resource referred to by path. - - - - - Name of the algorithm whereby the checksum was computed. - - - - - - Extracted file containing the serialized information. - - - From 2f52f630241fd791828c0208393f07bca7ccf78c Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 17 Oct 2024 16:57:59 +0200 Subject: [PATCH 09/14] bring in NXcalibration from instrument branch --- base_classes/NXcalibration.nxdl.xml | 95 +++++++++++++---------------- 1 file changed, 41 insertions(+), 54 deletions(-) diff --git a/base_classes/NXcalibration.nxdl.xml b/base_classes/NXcalibration.nxdl.xml index 702688fc2..9aa6038a2 100644 --- a/base_classes/NXcalibration.nxdl.xml +++ b/base_classes/NXcalibration.nxdl.xml @@ -21,16 +21,11 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays - - - Number of coefficients of the calibration function - - Number of points of the calibrated and uncalibrated axes @@ -51,20 +46,20 @@ energy, momentum, time, etc. - + A digital persistent identifier (e.g., DOI, ISO standard) referring to a detailed description of a calibration method but no actual calibration data. - - + + A digital persistent identifier (e.g., a DOI) referring to a publicly available calibration measurement used for this instrument, e.g., a measurement of a known standard containing calibration information. The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - - + + A file serialisation of a calibration which may not be publicly available (externally from the nexus file). @@ -85,16 +80,6 @@ Has the calibration been applied? - - - Name of the software used for this calibration. - - - - Software version. - - - Vector containing the data coordinates in the original uncalibrated axis @@ -120,60 +105,68 @@ - + Additional input axis to be used in the formula. - The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., - if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. - - - - + - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + The name of each ``TERM`` is used as the symbol to be used in the ``fit_formula_description``, i.e., + if the field name is `my_field` you should refer to this axis by `my_field` in the ``fit_formula_description``. - - - + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. + E(TOF). Here we can store the fit coefficients. - - - - - + + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the ``fit_formula_description``. + + + + - For non-linear energy calibrations. Here we can store the formula of the - fit function. + For non-linear energy calibrations. Here we can store a description of the formula + used for the fit function. - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients group. Use x0, x1, ..., xn for the nth position in the `original_axis` field. If there is the symbol attribute specified for the `original_axis` this may be used instead of x. If you want to use the whole axis use `x`. - Alternate axis can also be available as specified by the `input_SYMBOL` field. + Alternate axis can also be available as specified by the `input_SYMBOL` group. The data should then be referred here by the `SYMBOL` name, e.g., for a field name `input_my_field` it should be referred here by `my_field` or `my_field0` if you want to read the zeroth element of the array. - - The formula should be numpy compliant. - + For linear calibration. Scaling parameter. - This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + This should yield the relation `calibrated_axis` = (`original_axis` + `offset`) * `scaling_factor`. + + For a more detailed description of scaling factors, see + :ref:`FIELDNAME_scaling_factor </NXdata@FIELDNAME_scaling_factor-field>`. + For linear calibration. Offset parameter. - This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + This should yield the relation `calibrated_axis` = (`original_axis` + `offset`) * `scaling_factor`. + + For a more detailed description of offset, see + :ref:`FIELDNAME_offset </NXdata@FIELDNAME_offset-field>`. @@ -191,12 +184,6 @@ - - - The path to which this data is written, e.g., the calibrated energy. - Should be a valid NeXus path name, e.g., /entry/data/energy. - - From 49af954c66b510b0268a90807c570f9b6162c2e2 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 6 Dec 2024 13:05:53 +0100 Subject: [PATCH 10/14] push back NXfabrication to contributed --- .../NXfabrication.nxdl.xml | 51 +++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 contributed_definitions/NXfabrication.nxdl.xml diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml new file mode 100644 index 000000000..1f940f079 --- /dev/null +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -0,0 +1,51 @@ + + + + + + Details about a component as defined by its manufacturer. + + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + + + Free-text list with eventually multiple terms of + functionalities which the component offers. + + + + From 4290e0465d8ba197946fd3b7baad86a0aee6203a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 9 Dec 2024 09:58:56 +0100 Subject: [PATCH 11/14] fix some links --- base_classes/NXcalibration.nxdl.xml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/base_classes/NXcalibration.nxdl.xml b/base_classes/NXcalibration.nxdl.xml index 9aa6038a2..1c01b1aba 100644 --- a/base_classes/NXcalibration.nxdl.xml +++ b/base_classes/NXcalibration.nxdl.xml @@ -156,8 +156,7 @@ This should yield the relation `calibrated_axis` = (`original_axis` + `offset`) * `scaling_factor`. For a more detailed description of scaling factors, see - :ref:`FIELDNAME_scaling_factor </NXdata@FIELDNAME_scaling_factor-field>`. - + :ref:`FIELDNAME_scaling_factor </NXdata/FIELDNAME_scaling_factor-field>`. @@ -166,7 +165,7 @@ This should yield the relation `calibrated_axis` = (`original_axis` + `offset`) * `scaling_factor`. For a more detailed description of offset, see - :ref:`FIELDNAME_offset </NXdata@FIELDNAME_offset-field>`. + :ref:`FIELDNAME_offset </NXdata/FIELDNAME_offset-field>`. From fba820eb4a163f3583d476d81b57d81da55fffb4 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 18 Dec 2024 17:47:42 +0100 Subject: [PATCH 12/14] make NXregistration a subclass of NXprocess --- base_classes/NXregistration.nxdl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/base_classes/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml index 5499c842b..cbec502bc 100644 --- a/base_classes/NXregistration.nxdl.xml +++ b/base_classes/NXregistration.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Describes image registration procedures. From f0852f2f0027c8ededa0128f7155dd782a9c65d8 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 19 Dec 2024 12:07:47 +0100 Subject: [PATCH 13/14] remove NXcalibration from base classes --- base_classes/NXcalibration.nxdl.xml | 206 ------------------ .../NXcalibration.nxdl.xml | 111 ++++++++++ 2 files changed, 111 insertions(+), 206 deletions(-) delete mode 100644 base_classes/NXcalibration.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml diff --git a/base_classes/NXcalibration.nxdl.xml b/base_classes/NXcalibration.nxdl.xml deleted file mode 100644 index 1c01b1aba..000000000 --- a/base_classes/NXcalibration.nxdl.xml +++ /dev/null @@ -1,206 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - A description of the procedures employed. - - - - - The physical quantity of the calibration, e.g., - energy, momentum, time, etc. - - - - - A digital persistent identifier (e.g., DOI, ISO standard) referring to a detailed description of a - calibration method but no actual calibration data. - - - - - A digital persistent identifier (e.g., a DOI) referring to a publicly available calibration measurement - used for this instrument, e.g., a measurement of a known standard containing calibration information. - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - - - - - A file serialisation of a calibration which may not be publicly available (externally from the nexus file). - - This metadata can be a documentation of the source (file) or database (entry) from which pieces - of information have been extracted for consumption (e.g. in a research data management system (RDMS)). - It is also possible to include the actual file by using the `file` field. - - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. - This should comply to the following naming rules (similar to python's naming rules): - - * A variable name must start with a letter or the underscore character - * A variable name cannot start with a number - * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) - * Variable names are case-sensitive (age, Age and AGE are three different variables) - - - - - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - - - - - - Additional input axis to be used in the formula. - - - - The name of each ``TERM`` is used as the symbol to be used in the ``fit_formula_description``, i.e., - if the field name is `my_field` you should refer to this axis by `my_field` in the ``fit_formula_description``. - - - - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - - - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the fit coefficients. - - - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the ``fit_formula_description``. - - - - - - For non-linear energy calibrations. Here we can store a description of the formula - used for the fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients group. - - Use x0, x1, ..., xn for the nth position in the `original_axis` field. - If there is the symbol attribute specified for the `original_axis` this may be used instead of x. - If you want to use the whole axis use `x`. - Alternate axis can also be available as specified by the `input_SYMBOL` group. - The data should then be referred here by the `SYMBOL` name, e.g., for a field - name `input_my_field` it should be referred here by `my_field` or `my_field0` if - you want to read the zeroth element of the array. - - - - - For linear calibration. Scaling parameter. - This should yield the relation `calibrated_axis` = (`original_axis` + `offset`) * `scaling_factor`. - - For a more detailed description of scaling factors, see - :ref:`FIELDNAME_scaling_factor </NXdata/FIELDNAME_scaling_factor-field>`. - - - - - For linear calibration. Offset parameter. - This should yield the relation `calibrated_axis` = (`original_axis` + `offset`) * `scaling_factor`. - - For a more detailed description of offset, see - :ref:`FIELDNAME_offset </NXdata/FIELDNAME_offset-field>`. - - - - - Mapping data for calibration. - - This can be used to map data points from uncalibrated to calibrated values, - i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Any data acquired/used during the calibration that does not fit the `NX_FLOAT` fields above. - NXdata groups can be used for multidimensional data which are relevant to the calibration - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + From 75fe5bb2ace5af7a5b4f23810fa7548d0325f05d Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 8 Jan 2025 14:59:13 +0100 Subject: [PATCH 14/14] remove NXfabrication from contributed --- .../NXfabrication.nxdl.xml | 51 ------------------- 1 file changed, 51 deletions(-) delete mode 100644 contributed_definitions/NXfabrication.nxdl.xml diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml deleted file mode 100644 index 1f940f079..000000000 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - Details about a component as defined by its manufacturer. - - - - Company name of the manufacturer. - - - - - Version or model of the component named by the manufacturer. - - - - - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. - - - - - Free-text list with eventually multiple terms of - functionalities which the component offers. - - - -