diff --git a/base_classes/NXactivity.nxdl.xml b/base_classes/NXactivity.nxdl.xml new file mode 100644 index 0000000000..f354de06d2 --- /dev/null +++ b/base_classes/NXactivity.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + A planned or unplanned action that has a temporal extension and for some time depends on some entity. + + This class is planned be used in the future as the super class for all other activities if inheritance + in base classes is supported in NeXus. + + + + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this activity started. + + + + + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this activity ended. + + + + + Short description of the activity. + + + + + This can be any data or other descriptor acquired during the activity + (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + diff --git a/base_classes/NXcalibration.nxdl.xml b/base_classes/NXcalibration.nxdl.xml new file mode 100644 index 0000000000..702688fc2c --- /dev/null +++ b/base_classes/NXcalibration.nxdl.xml @@ -0,0 +1,220 @@ + + + + + + + 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/contributed_definitions/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml similarity index 76% rename from contributed_definitions/NXchamber.nxdl.xml rename to base_classes/NXchamber.nxdl.xml index edf318e2af..f6cbac9137 100644 --- a/contributed_definitions/NXchamber.nxdl.xml +++ b/base_classes/NXchamber.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Component of an instrument to store or place objects and specimens. + Base class for a chamber in an instrument that stores real or simulated objects. - + - Given name/alias. + Given name for the chamber of this component e.g. analysis chamber + or buffer chamber, load-lock chamber, microscope column, glove box. - + Free-text field for describing details about the chamber. For example out of which material was the chamber built. diff --git a/base_classes/NXcircuit.nxdl.xml b/base_classes/NXcircuit.nxdl.xml new file mode 100644 index 0000000000..9648ae103a --- /dev/null +++ b/base_classes/NXcircuit.nxdl.xml @@ -0,0 +1,136 @@ + + + + + + Base class for circuit devices. + + + + Hardware type used in circuit, includes hardware manufacturers and type + + + + + The tunneling current between tip and sample after application of bias voltage. + + + + + Calibration of the current measurement (A/V). + + + + + Offset of the current measurement. + + + + + Proportional relationship between the probe output voltage and the actual + tunneling current when measuring the tunneling current. + + + + + The scan channels are selected by users (in scan contronaller). + + + + + The bandwitdh of the Hardware and/or Software + + + + + (Signals Periods) The Signals Period is the rate at which the signals are + transferred to the host computer running the control software. This is usually + lower by a factor of 10 than the sampling rate, because an internal oversampling + of the signal is done on the real time engine. You can reduce the oversampling + down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + + + + + Update rate for several processes like History Graph, Auto-Approach, and for + many Programming Interface functions. This is usually set to 20 ms. All + additional timings (7-9) can only be integer multiples of this value. They can + be set to different values, but the actual timing value will be coerced to a + multiple of the Acquisition Period. + + + + + Update rate of animated graphical indicators. These are e.g. some graphs & + sliders. A reasonable value is 40 ms (25 updates per second). Increase this + period to reduce the processor load for the graphical user interface, especially + on slow computers. This value is purely a user interface update rate and does + not affect measurements in any way. + + + + + Update rate of digital indicators, e.g. the numbers displayed besides each + slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a + user interface update rate and does not affect measurements in any way. + + + + + The Measurements period is the integration time for precise measurements + (averaging over specified period), mostly used in sweep modules. Examples are + recording of a force-distance curve or a resonance of a cantilever. For fast + measurements with small steps, a value of 40 ms may be reasonable. For normal + use, 300-500 ms is a good value, but for recording a resonance of a high-Q + cantilever, values of several seconds might be necessary. Usually this parameter + doesn’t need to be set from this module; the sweep modules will set this value + according to the sweep timings. + + + + + Number of output channels + + + + + The user output in each monitor mode. + + + + + The values for each output channel. + + + + + User outputs whose name can be modified in the corresponding module. + + + + + The rate at which the one of the signal changes when ramping to the starting + point. (V/s) + + + diff --git a/base_classes/NXcomponent.nxdl.xml b/base_classes/NXcomponent.nxdl.xml new file mode 100644 index 0000000000..d317db6803 --- /dev/null +++ b/base_classes/NXcomponent.nxdl.xml @@ -0,0 +1,64 @@ + + + + + + Base class for components of an instrument - real ones or a simulated ones. + + + + Specifies the position of the component by pointing to the last + transformation in the transformation chain that is defined + via the NXtransformations group. + + + + + Was the component used? + + + + + Given name + + + + + Ideally, use instances of :ref:`NXidentifier` to point to a resource + that provides further details. + + If such a resource does not exist or should not be used, use this, though + discouraged, free-text. + + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + + diff --git a/base_classes/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml new file mode 100644 index 0000000000..80de81f407 --- /dev/null +++ b/base_classes/NXcoordinate_system.nxdl.xml @@ -0,0 +1,159 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the third axis which spans the coordinate system. + This axis is frequently referred to as the z-axis in real space and + the k-axis in reciprocal space. + + + + + + + + This specificies the relation to another coordinate system by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe this coordinate system + with respect to another coordinate system. + + + diff --git a/base_classes/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml new file mode 100644 index 0000000000..a842d257d2 --- /dev/null +++ b/base_classes/NXcoordinate_system_set.nxdl.xml @@ -0,0 +1,240 @@ + + + + + + + Base class to hold different coordinate systems and representation conversions. + + How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? + + * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across + the application definition, an instance of NXcoordinate_system is defined, + the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ + coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and + NXcoordinate_system base classes backwards compatible to older + NeXus conventions and classes. + * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed + as high up in the node hierarchy (ideally right below an instance of NXentry) + of the application definition tree as possible. + This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system + instance. This shall be named such that it is clear how this coordinate system is + typically referred to in a community. For the NeXus `McStas coordinate system, it is + advised to call it mcstas for the sake of improved clarity. + Additional NXcoordinate_system instances should be specified if possible in that same + :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. + + If this is the case, it is assumed that the NXcoordinate_system_members + overwrite the NeXus default McStas coordinate system, i.e. users can thereby + conveniently and explicitly specify the coordinate system(s) that + they wish to use. + + Users are encouraged to write also explicit and clean depends_on fields in + all groups that encode information about where the interpretation of coordinate + systems is relevant. If these depends_on hints are not provided, it is + automatically assumed that all children (to arbitrary depth) + of that branch and sub-branches below the one in which that + :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set + instance in that set or the application definition is considered + underconstrained which should at all costs be avoided and in which case + again McStas is assumed. + * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified + somewhere in the tree, different interpretations are possible as to which + of these coordinate system sets and instances apply or take preference. + We realize that such ambiguities should at all costs be avoided. + However, the opportunity for multiple sets and their instances enables to + have branch-specific coordinate system conventions which could especially + be useful for deep classes where multiple scientific methods are combined or + cases where having a definition of global translation and conversion tables + how to convert between representations in different coordinate systems + is not desired or available for now. + We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective + NXcoordinate_system instances makes the interpretation eventually unnecessary + complicated. Instead, developers of application definitions should always try + to work for clarity and thus use only one top-level coordinate system set. + + For these reasons we conclude that the option with one top-level + :ref:`NXcoordinate_system_set` instance is the preferred choice. + + McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance + of NXcoordinate_system is specified. However, even in this case it is better + to be explicit like for every other coordinate system definition to support + users with interpreting the content and logic behind every instance of the tree. + + How to store coordinate systems inside :ref:`NXcoordinate_system_set`? + Individual coordinate systems should be specified as members of the + :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. + + How many individual instances of NXcoordinate_system to allow within one + instance of :ref:`NXcoordinate_system_set`? + + * 0; This case should be avoided for the sake of clarity but this case could + mean the authors of the definition meant that McStas is used. We conclude, + McStas is used in this case. + * 1; Like above-mentioned this case has the advantage that it is explicit + and faces no ambiguities. However, in reality typically multiple + coordinate systems have to be mastered especially for complex + multi-signal modality experiments. + * 2 or more; If this case is realized, the best practice is that in every + case where a coordinate system should be referred to the respective class + has a depends_on field which resolves the possible ambiguities which specific + coordinate systems is referred to. The benefit of this explicit and clear + specifying of the coordinate system used in every case is that especially + in combination with having coordinate systems inside deeper branches + makes up for a very versatile, backwards compatible, but powerful system + to express different types of coordinate systems using NeXus. In the case + of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, + it is also advised to specify the relationship between the two coordinate systems by + using the (NXtransformations) group within NXcoordinate_system. + + In effect, 1 should be the preferred choice. However, if more than one coordinate + system is defined for practical purposes, explicit depends_on fields should + always guide the user for each group and field which of the coordinate system + one refers to. + + + + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin, + i.e. in accordance with convention 2 of + DOI: 10.1088/0965-0393/23/8/083501. + Counter_clockwise is equivalent to a right-handed choice. + Clockwise is equivalent to a left-handed choice. + + + + + + + + + + How are rotations interpreted into an orientation + according to convention 3 of + DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + + How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) + according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. + + The most frequently used convention is zxz, which is based on the work of H.-J. Bunge + but other conventions are possible. Apart from undefined, proper Euler angles + are distinguished from (improper) Tait-Bryan angles. + + + + + + + + + + + + + + + + + + + + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + Which sign convention is followed when converting orientations + between different parameterizations/representations according + to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + + + + + Details about eventually relevant named directions that may give reasons for anisotropies. + The classical example is mechanical processing where one has to specify which directions + (e.g. rolling, transverse, and normal direction) align how with the direction of the base + vectors of the sample_reference_frame. + + It is assumed that the configuration is inspected by looking towards the sample surface. + If a detector is involved, it is assumed that the configuration is inspected from a position + that is located behind this detector. + + If any of these assumptions is not met, the user is required to explicitly state this. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the + base vectors of this coordinate system as Xp, Yp, Zp. + + + + + Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. + + It is assumed that the configuration is inspected by looking towards the sample surface. + If a detector is involved, it is assumed that the configuration is inspected from a position + that is located behind this detector. + + If any of these assumptions is not met, the user is required to explicitly state this. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the + base vectors of this coordinate system as Xs, Ys, Zs. + + + + + Details about the detector_reference_frame for a specific detector. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the + base vectors of this coordinate system as Xd, Yd, Zd. + + It is assumed that the configuration is inspected by looking towards the sample surface + from a position that is located behind the detector. + + If any of these assumptions is not met, the user is required to explicitly state this. + + + diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml new file mode 100644 index 0000000000..6303eb3ae7 --- /dev/null +++ b/base_classes/NXcs_computer.nxdl.xml @@ -0,0 +1,146 @@ + + + + + + Base class for reporting the description of a computer + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + Details about the system of processing units e.g. (classical) processing units (CPUs), + coprocessor, graphic cards, accelerator processing units or a system of these. + + + + Granularizing the processing units. Typical examples, a desktop computer + with a single CPU one could describe using one instance of NXcircuit. + A dual-socket server one could describe using two instances NXcircuit + A server with two dual-socket server nodes one could describe with + four instances of NXcircuit surplus a field with their level in the hierarchy. + + + + General type of the processing unit + + + + + + + + + + + Given name + + + + + + + Details about the memory system. + + + + Granularizing the components of the memory system. + + + + Qualifier for the type of random access memory. + + + + + + + + + Total amount of data which the medium can hold. + + + + + Given name + + + + + + + Details about the I/O system. + + + + Granularizing the components of the I/O system. + + + + Qualifier for the type of storage medium used. + + + + + + + + + + Total amount of data which the medium can hold. + + + + + Given name + + + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 72% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml index 97105a1b25..d37224f9cb 100644 --- a/contributed_definitions/NXcs_profiling.nxdl.xml +++ b/base_classes/NXcs_profiling.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description for summary performance/profiling data of an application. + Computer science description for performance and profiling data of an application. Performance monitoring and benchmarking of software is a task where questions can be asked at various levels of detail. In general, there are three main @@ -38,28 +38,29 @@ * Software configuration and capabilities * Dynamic effects of the system in operation and the system working together with eventually multiple computers, especially when these have to exchange - information across a network. + information across a network and these are used usually by multiple users. At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. + analysis with a scientific software (app) took. + A frequent idea is here to answer practical questions like how critical is the + effect on the workflow of the scientists, i.e. is the analysis possible in + a few seconds or would it take days if I were to run this analysis on a + comparable machine? + For this more qualitative performance monitoring, mainly the order of + magnitude is relevant, as well as how this was achieved using parallelization + (i.e. reporting the number of CPU and GPU resources used, the number of + processes and threads configured, and providing basic details about the computer). At more advanced levels benchmarks may go as deep as detailed temporal tracking of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history + state of call stacks; in short eventually the entire app execution history and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. + optimization, i.e. by software and hardware developers as well as for + tracking bugs. Specialized software exists which documents such performance + data in specifically-formatted event log files or databases. - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the + This base class cannot and should not replace these specific solutions for now. + Instead, the intention of the base class is to serve scientists at the basic level to enable simple monitoring of performance data and log profiling data of key algorithmic steps or parts of computational workflows, so that these pieces of information can guide users which order of magnitude differences @@ -70,12 +71,12 @@ the metadata in this base class. - + Path to the directory from which the tool was called. - + Command line call with arguments if applicable. @@ -97,15 +98,15 @@ Wall-clock time how long the app execution took. This may be in principle end_time minus start_time; however usage of eventually more precise timers may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. + and thus demands a more precise record of the wall-clock time. - + - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field e.g. for apps which use e.g. MPI + (Message Passing Interface) parallelization is to communicate + how many processes were used. For sequentially running apps number_of_processes and number_of_threads is 1. If the app uses exclusively GPU parallelization number_of_gpus @@ -114,14 +115,14 @@ used though. - + - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the + Qualifier how many nominal threads were used at runtime. + Specifically here the maximum number of threads used for the high-level threading library used (e.g. OMP_NUM_THREADS), posix. - + Qualifier with how many nominal GPUs the app was invoked at runtime. @@ -129,8 +130,7 @@ +complicated models should be captured.--> A collection with one or more computing nodes each with own resources. diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 82% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml index 195dee88c6..9da91f9c04 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/base_classes/NXcs_profiling_event.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -47,31 +47,34 @@ included when the event tracking ended. - + Free-text description what was monitored/executed during the event. - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. + Wall-clock time how long the event took. + + This may be in principle end_time minus start_time; however usage of + eventually more precise timers may warrant to use a finer temporal + discretization, and thus demand for a more precise record of the + wall-clock time. + Elapsed time may contain time portions where resources were idling. - + Number of processes used (max) during the execution of this event. - + Number of threads used (max) during the execution of this event. - + Number of GPUs used (max) during the execution of this event. diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 77% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml index abdea5bbbf..10e699c881 100644 --- a/contributed_definitions/NXdeflector.nxdl.xml +++ b/base_classes/NXdeflector.nxdl.xml @@ -1,10 +1,10 @@ - + - + Deflectors as they are used e.g. in an electron analyser. - + - Qualitative type of deflector with respect to the number of pole pieces + Qualitative type of deflector with respect to the number of pole pieces. @@ -36,52 +36,54 @@ - + Colloquial or short name for the deflector. For manufacturer names and identifiers use respective manufacturer fields. - + + - Name of the manufacturer who built/constructed the deflector. + Ideally an identifier, persistent link, or free text which gives + further details about the deflector. - + - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. + Excitation voltage of the deflector. For dipoles it is a single number. + For higher order multipoles, it is an array. - + - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - + - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. + Spatial offset of the deflector in x direction (perpendicular to + ```offset_y```). - + - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. + Spatial offset of the deflector in y direction (perpendicular to + ```offset_x```). - + Specifies the position of the deflector by pointing to the last transformation in the transformation chain in the NXtransformations group. - + Collection of axis-based translations and rotations to describe the location and geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate + :ref:`NXtransformations` base class are used. In principle, the McStas coordinate system is used. The first transformation has to point either to another component of the system or . (for pointing to the reference frame) to relate it relative to the experimental setup. Typically, the components of a system should diff --git a/base_classes/NXfit_function.nxdl.xml b/base_classes/NXfit_function.nxdl.xml new file mode 100644 index 0000000000..de6a1e585b --- /dev/null +++ b/base_classes/NXfit_function.nxdl.xml @@ -0,0 +1,76 @@ + + + + + + This describes a fit function that is used to fit data to any functional form. + + A fit function is used to describe a set of data :math:`y_k, k = 1 ... M`, which are collected as a function + of one or more independent variables :math:`x` at the points :math:`x_k`. The fit function :math:`f` describes + these data in an approximative way as :math:`y_k \approx f(a_0, . . . a_n, x_k)`, + where :math:`a_i, i = 0 . . . n` are the *fit parameters* (which are stored the instances of ``NXfit_parameter``). + + + + Human-readable description of this fit function. + + + + + Mathematical formula of the function, taking into account the instances of ``NXfit_parameter``. + + This should be a python parsable function. Here we should provide which keywords are available + and a BNF of valid grammar. + + + + + + A parameter for a fit function. + This would typically be a variable that + is optimized in a fit. + + + + A description of what this parameter represents. + + + + + The value of the parameter. After fitting, this would store the + optimized value. + + + + + The minimal value of the parameter, to be used as a constraint during fitting. + + + + + The maximal value of the parameter, to be used as a constraint during fitting. + + + + + diff --git a/base_classes/NXhistory.nxdl.xml b/base_classes/NXhistory.nxdl.xml new file mode 100644 index 0000000000..9dfa25d722 --- /dev/null +++ b/base_classes/NXhistory.nxdl.xml @@ -0,0 +1,74 @@ + + + + + + A set of activities that occurred to a physical entity prior/during experiment. + + Ideally, a full report of the previous operations (or links to a chain of operations). + Alternatively, notes allow for additional descriptors in any format. + + + + Any activity that was performed on the physical entity prior or during the experiment. In + the future, if there is base class inheritance, this can describe any activity, + including processes and measurements. + + + + + + Any physical process that was performed on the physical entity prior or during the + experiment. + + + + + Any chemical process that was performed on the physical entity prior or during the + experiment. + + + + + An ID or reference to the location or a unique (globally + persistent) identifier of e.g. another file which gives + as many as possible details of the history event. + + + + + + A descriptor to keep track of the treatment of the physical entity before or during the + experiment (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + This should only be used in case that there is no rigorous description + using the base classes above. This field can also be used to pull in any activities + that are not well described by an existing base class definition. + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml new file mode 100644 index 0000000000..9106ef84f2 --- /dev/null +++ b/base_classes/NXimage_set.nxdl.xml @@ -0,0 +1,652 @@ + + + + + + + + + + Number of images in the stack, for stacks the slowest dimension. + + + + + Number of image points along the slow dimension (k equivalent to z). + + + + + Number of image points along the fast dimension (j equivalent to y). + + + + + Number of image points along the fastest dimension (i equivalent to x). + + + + + Base class for reporting a set of images. + + The mostly commonly used scanning methods are supported. That is one-, + two-, three-dimensional ROIs discretized using regular Euclidean tilings. + + Colloquially, an image is understood as a discretized representation of intensity distribution + that was detected or simulated for some ROI. When discretized with regular Euclidean tilings + the terms pixel and voxel identify the smallest discretization unit. Pixel and voxel are polygonal + or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. + For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term + (image) point is eventually is more appropriate for such tilings. Therefore, all docstrings in this base class + refer to points (including pixel and voxel i.e. regular tilings). + + Point coordinates identify the location of the barycentre. + + For images in reciprocal space in practice, complex numbers are encoded via some + formatted pair of real values. Typically, fast algorithms for computing Fourier transformations + (FFT) are used to encode images in reciprocal (frequency) space. FFT libraries are used + for implementing the key functionalities of these mathematical operations. + + Different libraries use different representations and encoding of the images. + Details can be found in the respective sections of the typical FFT libraries documentations + + * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ + * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2024-2/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + * `NFFT by the Chemnitz group <https://www-user.tu-chemnitz.de/~potts/nfft/>`_ for non-equispaced computations + + Users are strongly advised to inspect carefully which specific conventions their library uses + to enable storing and modifying the implementation of their code such that the serialized + representations as they are detailed here for NeXus match. + + It is often the case that several images are combined using processing. In this case, + the number of images which are combined in a collection is not necessarily the same + for each collection. The NXimage_set base class addresses this logical distinction + through the notation of image_identifier and group_identifier concepts. + That is image_identifier are always counting from offset in increments of one. + as each image is its own entity. By contrast, a group may contain no, or several images. + Consequently, group_identifier are not required to be contiguous. + + + + Details how NXdata instance were processed from detector readings/raw data. + + + + Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` + instances in this :ref:`NXimage_set` were loaded during parsing. + + Possibility to document from which specific other serialized resource as the source + pieces of information were processed when using NeXus as a semantic file format + to serialize that information differently. + + The group in combination with an added field *absolute_path* therein adds context. + + + + Reference to a location inside the artifact that points to the specific group of values + that were processed if the artifacts contains several groups of values and thus + further resolving of ambiguities is required. + + + + + + + Link or name of an :ref:`NXdetector` instance with which the data were + collected. + + + + + Program used for processing. + + + + + + + One-dimensional image. + + + + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + + + + + + + + Real part of the image intensity per point. + + + + + + + + Imaginary part of the image intensity per point. + + + + + + + + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. + + + + + + + + Point coordinate along the fastest dimension. + + + + + + + Point coordinate along the fastest dimension. + + + + + + + Two-dimensional image. + + + + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + + + + + + + + + Real part of the image intensity per point. + + + + + + + + + Imaginary part of the image intensity per point. + + + + + + + + + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. + + + + + + + + + Point coordinate along the fast dimension. + + + + + + + Point coordinate along the fast dimension. + + + + + + Point coordinate along the fastest dimension. + + + + + + + Point coordinate along the fastest dimension. + + + + + + + Three-dimensional image. + + + + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + + + + + + + + + + Real part of the image intensity per point. + + + + + + + + + + Imaginary part of the image intensity per point. + + + + + + + + + + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. + + + + + + + + + + Point coordinate along the slow dimension. + + + + + + + Point coordinate along the slow dimension. + + + + + + Point coordinate along the fast dimension. + + + + + + + Point coordinate along the fast dimension. + + + + + + Point coordinate along the fastest dimension. + + + + + + + Point coordinate along the fastest dimension. + + + + + + + Collection of image_1d. + + + + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + + + + + + + + + Real part of the image intensity per point. + + + + + + + + + Imaginary part of the image intensity per point. + + + + + + + + + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. + + + + + + + + + Group identifier + + + + + + + Group identifier + + + + + + Image identifier + + + + + + + Image identifier + + + + + + Point coordinate along the fastest dimension. + + + + + + + Point coordinate along the fastest dimension. + + + + + + + Collection of two-dimensional images. + + + + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + + + + + + + + + + Real part of the image intensity per point. + + + + + + + + + + Imaginary part of the image intensity per point. + + + + + + + + + + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. + + + + + + + + + + Group identifier + + + + + + + Group identifier + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Point coordinate along the fast dimension. + + + + + + + Point coordinate along the fast dimension. + + + + + + Point coordinate along the fastest dimension. + + + + + + + Point coordinate along the fastest dimension. + + + + + + + Collection of three-dimensional images. + + + + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. + + + + + + + + + + + Real part of the image intensity per point. + + + + + + + + + + + Imaginary part of the image intensity per point. + + + + + + + + + + + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. + + + + + + + + + + + Group identifier + + + + + + + Group identifier + + + + + + Image identifier + + + + + + + Image identifier + + + + + + Point coordinate along the slow dimension. + + + + + + + Point coordinate along the slow dimension. + + + + + + Point coordinate along the fast dimension. + + + + + + + Point coordinate along the fast dimension. + + + + + + Point coordinate along the fastest dimension. + + + + + + + Point coordinate along the fastest dimension. + + + + + diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml new file mode 100644 index 0000000000..ee278ead9e --- /dev/null +++ b/base_classes/NXion.nxdl.xml @@ -0,0 +1,158 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Base class for documenting the set of atoms of a (molecular) ion. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. + + The identifier zero is reserved for the special unknown ion type. + + + + + Vector of nuclide hash values. + + Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` + encode the number of protons :math:`Z` and the number of neutrons :math:`N` + of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. + + The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. + The first column specifies the nuclide mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no + isotope-specific information about the element encoded is relevant. + The second row specifies the number of protons :math:`Z` or 0. + The value 0 in this case documents a placeholder or that no element-specific + information is relevant. + Taking a carbon-14 nuclide as an example the mass number is 14. + That is encoded as a value pair (14, 6) as one row of the table. + + Therefore, this notation is the typical superscribed nuclide mass number + and subscripted number of protons element notation e.g. :math:`^{14}C`. + The array is stored matching the order of nuclide_hash. + + + + + + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored alongside ranging + definitions. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + In the example of atom probe microscopy, only positive values will be measured + as the ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, the value should + be set to zero. + + In atom probe microscopy this is for example the case when using + classical ranging definition files in formats like RNG, RRNG. + These file formats do not document the charge state explicitly + but the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + Details on ranging definition files can be found in the literature: + `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of UTF-8 characters, ideally using LaTeX + notation to specify the isotopes, ions, and charge state. + Examples are 12C + or Al +++. + + To ease automated parsing, isotope_vector should be the + preferred machine-readable information used. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of the + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries inclusive). This field is primarily of interest + for documenting :ref:`NXprocess` steps of indexing a + ToF/mass-to-charge state histogram. + + + + + + + diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml new file mode 100644 index 0000000000..e878d25e35 --- /dev/null +++ b/base_classes/NXlens_em.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + + + Base class for an electro-magnetic lens or a compound lens. + + For :ref:`NXtransformations` the origin of the coordinate system is placed + in the center of the lens (its polepiece, pinhole, or another + point of reference). The origin should be specified in the :ref:`NXtransformations`. + + For details of electro-magnetic lenses in the literature + see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + + Descriptor for the lens excitation when the exact technical details + are unknown or not directly controllable as the control software of + the microscope does not enable or was not configured to display these + values (for end users). + + Although this value does not document the exact physical voltage or + excitation, it can still give useful context to reproduce the lens + setting, provided a properly working instrument and software sets the lens + into a similar state to the technical level possible when no more + information is available physically or accessible legally. + + + + + Descriptor for the operation mode of the lens when other details are not + directly controllable as the control software of the microscope + does not enable or is not configured to display these values. + + Like value, the mode can only be interpreted for a specific microscope + but can still be useful to guide users as to how to repeat the measurement. + + + + + + Excitation voltage of the lens. + + For dipoles it is a single number. + For higher order multipoles, it is an array. + + + + + Excitation current of the lens. + + For dipoles it is a single number. + For higher-order multipoles, it is an array. + + + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + diff --git a/base_classes/NXmanipulator.nxdl.xml b/base_classes/NXmanipulator.nxdl.xml new file mode 100644 index 0000000000..a057a167df --- /dev/null +++ b/base_classes/NXmanipulator.nxdl.xml @@ -0,0 +1,257 @@ + + + + + + Extension of NXpositioner to include fields to describe the use of manipulators + in photoemission experiments. + + + + Name of the manipulator. + + + + + A description of the manipulator. + + + + + Type of manipulator, Hexapod, Rod, etc. + + + + + Cryostat for cooling the sample. + + + + + + + + + + In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. + It can also be a 1D array of temperature setpoints (without time stamps). + + + + + + In the case of an experiment in which the temperature is changed and the setpoints are + recorded with time stamps, this is an array of length m of temperature setpoints. + + + + + + + + Temperature sensor measuring the sample temperature. + + + + + + + + + In case of a single or averaged temperature measurement, this is the scalar temperature measured + by the sample temperature sensor. It can also be a 1D array of measured temperatures + (without time stamps). + + + + + + In the case of an experiment in which the temperature changes and is recorded with time stamps, + this is an array of length m of temperatures. + + + + + + + Device to heat the sample. + + + + + + + + + In case of a fixed or averaged heating power, this is the scalar heater power. + It can also be a 1D array of heater powers (without time stamps). + + + + + + In the case of an experiment in which the heater power is changed and recorded with time stamps, + this is an array of length m of temperature setpoints. + + + + + + + In case of a fixed or averaged temperature, this is the scalar temperature setpoint. + It can also be a 1D array of temperature setpoints (without time stamps). + + + + + + In the case of an experiment in which the temperature is changed and the setpoints are + recorded with time stamps, this is an array of length m of temperature setpoints. + + + + + + + + Amperemeter measuring the drain current of the sample and sample holder. + + + + + + + + + In case of a single or averaged drain current measurement, this is the scalar drain current measured between + the sample and sample holder. It can also be an 1D array of measured currents (without time stamps). + + + + + + In the case of an experiment in which the current changes and is recorded with + time stamps, this is an array of length m of currents. + + + + + + + Actuator applying a voltage to sample and sample holder. + + + + + + + + + + In case of a fixed or averaged applied bias, this is the scalar voltage applied between + sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). + + + + + + In the case of an experiment in which the bias is changed and the setpoints are + recorded with time stamps, this is an array of length m of voltage setpoints. + + + + + + + + Sensor measuring the voltage applied to sample and sample holder. + + + + + + + + + In case of a single or averaged bias measurement, this is the scalar voltage measured between + sample and sample holder. It can also be an 1D array of measured voltages (without time stamps). + + + + + + In the case of an experiment in which the bias changes and is recorded with + time stamps, this is an array of length m of voltages. + + + + + + + Any additional actuator on the manipulator used to control an external + condition. + + + + + Any additional sensors on the manipulator used to monitor an external condition. + + + + + Class to describe the motors that are used in the manipulator + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the manipulator as a component in the instrument. Conventions from + the NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + + + .. 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/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml new file mode 100644 index 0000000000..86809edda6 --- /dev/null +++ b/base_classes/NXpeak.nxdl.xml @@ -0,0 +1,86 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Rank of the dependent and independent data arrays (for + multidimensional/multivariate fit.) + + + + + Base class for describing a peak, its functional form, and support values + (i.e., the discretization (points) at which the function has been evaluated). + + + + Human-readable label which specifies which concept/entity + the peak represents/identifies. + + + + + + Position values along one or more data dimensions (to hold the + values for the independent variable). + + + + The ``position`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``intensity`` field. + + + + + + This array holds the intensity/count values of the fitted peak at each position. + + + + The ``intensity`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``position`` field. + + + + + + + The functional form of the peak. This could be a Gaussian, Lorentzian, + Voigt, etc. + + + + + Total area under the curve. + + + diff --git a/contributed_definitions/NXpid.nxdl.xml b/base_classes/NXpid.nxdl.xml similarity index 70% rename from contributed_definitions/NXpid.nxdl.xml rename to base_classes/NXpid.nxdl.xml index 62fad3f835..4941cac937 100644 --- a/contributed_definitions/NXpid.nxdl.xml +++ b/base_classes/NXpid.nxdl.xml @@ -1,10 +1,10 @@ - + - + Contains the settings of a PID controller. @@ -53,12 +53,18 @@ It can also be a link to an NXsensor.value field. + + + Time log of the setpoint(s) used as an input for the PID controller. + + Proportional term. The proportional term produces an output value that is proportional to the current error value. The proportional response can be adjusted by multiplying the error by a constant Kp, called the proportional gain constant. + The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. @@ -81,4 +87,25 @@ action is termed the derivative gain, K_d + + + The Type switches controller parameters between P/I (proportional gain/integral + gain) and P/T (proportional gain/time constant). The formula for the controller + in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and + time constant are related as follows I = P/T. + + + + + .. 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/NXprogram.nxdl.xml b/base_classes/NXprogram.nxdl.xml similarity index 100% rename from contributed_definitions/NXprogram.nxdl.xml rename to base_classes/NXprogram.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 88% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml index 9f38b2d7b7..45a86edada 100644 --- a/contributed_definitions/NXpump.nxdl.xml +++ b/base_classes/NXpump.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Device to reduce an atmosphere to a controlled remaining pressure level. + Device to reduce an atmosphere (real or simulated) to a controlled pressure. - + Principle type of the pump. diff --git a/base_classes/NXresolution.nxdl.xml b/base_classes/NXresolution.nxdl.xml new file mode 100644 index 0000000000..4197d55506 --- /dev/null +++ b/base_classes/NXresolution.nxdl.xml @@ -0,0 +1,125 @@ + + + + + + Describes the resolution of a physical quantity. + + + + The physical quantity of the resolution, e.g., + energy, momentum, time, etc. + + + + + The process by which the resolution was determined. + + + + + + + + + + + Additional details of the estimate or description of the calibration procedure + + + + + The resolution of the physical quantity. + + + + + Standard deviation of the resolution of the physical quantity. + + + + + Ratio of the resolution at a specified measurand value to that measurand value, + + + + + Standard deviation of the relative resolution of the physical quantity. + + + + + The response of the instrument or part to a infinitesimally sharp input signal + along the physical quantity of this group. + This is also sometimes called instrument response function for time resolution or + point spread function for spatial response. + The resolution is typically determined by taking the full width at half maximum (FWHM) + of the response function. + + + + The input axis or grid of the response function. + The unit should match the one of the resolution field. + + + + + The magnitude of the response function corresponding to the points + in the input axis or grid. + This field should have the same dimensions as `input`. + + + + + + A symbol linking to another path in this appdef to be referred to from the + `resolution_formula` field. This should be a valid path inside this application + definition, i.e., of the form /entry/instrument/my_part/my_field. + + + + + A resolution formula to determine the resolution from a set of symbols as + entered by the `formula_...` fields. + The output unit should match the provided unit of this field. + + + + + .. 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. + + + + + For storing details and data of a calibration to derive a resolution from data. + + + diff --git a/base_classes/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml new file mode 100644 index 0000000000..94857e74cb --- /dev/null +++ b/base_classes/NXroi.nxdl.xml @@ -0,0 +1,34 @@ + + + + + + Base class to describe a region-of-interest analyzed. + + + + Details about processing steps. + + + + diff --git a/base_classes/NXrotation_set.nxdl.xml b/base_classes/NXrotation_set.nxdl.xml new file mode 100644 index 0000000000..3f47e3fb89 --- /dev/null +++ b/base_classes/NXrotation_set.nxdl.xml @@ -0,0 +1,256 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of value tuples. + + + + + How many phases with usually different crystal and symmetry are distinguished. + + + + + Base class to detail a set of rotations, orientations, and disorientations. + + For getting a more detailed insight into the discussion of the + parameterized description of orientations in materials science see: + + * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ + * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ + * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ + * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ + + Once orientations are defined, one can continue to characterize the + misorientation and specifically the disorientation. The misorientation describes + the rotation that is required to register the lattices of two oriented objects + (like crystal lattice) into a crystallographic equivalent orientation: + + * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ + + + + Reference to an instance of :ref:`NXcoordinate_system_set` which contextualizes + how the here reported parameterized quantities can be interpreted. + + + + + + Point group which defines the symmetry of the crystal. + + This has to be at least a single string. If crystal_symmetry is not + provided point group 1 is assumed. + + In the case that misorientation or disorientation fields are used + and the two crystal sets resolve for phases with a different + crystal symmetry, this field has to encode two string. + In this case the first string is for phase A the second one for phase B. + An example of this most complex case is the description of the + disorientation between crystals adjoining a hetero-phase boundary. + + + + + + + + Point group which defines an assumed symmetry imprinted upon processing + the material/sample which could give rise to or may justify to use a + simplified description of rotations, orientations, misorientations, + and disorientations via numerical procedures that are known as + symmetrization. + + If sample_symmetry is not provided point group 1 is assumed. + + The traditionally used symmetrization operations within the texture + community in Materials Science, though, are thanks to methodology and + software improvements no longer strictly needed. Therefore, users are + encouraged to set the sample_symmetry to 1 (triclinic) and thus assume + there is no justification to assume the imprinting of additional + symmetry because of the processing. + + In practice one often faces situations where indeed these assumed + symmetries are anyway not fully observed, and thus an accepting of + eventual inaccuracies just for the sake of reporting a simplified + symmetrized description should be avoided. + + + + + + + + The set of rotations expressed in quaternion parameterization considering + crystal_symmetry and sample_symmetry. Rotations which should be + interpreted as antipodal are not marked as such. + + + + + + + + + The set of rotations expressed in Euler angle parameterization considering + the same applied symmetries as detailed for the field rotation_quaternion. + To interpret Euler angles correctly, it is necessary to inspect the + conventions behind depends_on to resolve which of the many Euler-angle + conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + + + + + + + + + + + True for all those value tuples which have assumed antipodal symmetry. + False for all others. + + + + + + + + The set of orientations expressed in quaternion parameterization and + obeying symmetry for equivalent cases as detailed in crystal_symmetry + and sample_symmetry. The supplementary field is_antipodal can be used + to mark orientations with the antipodal property. + + + + + + + + + The set of orientations expressed in Euler angle parameterization following + the same assumptions like for orientation_quaternion. + To interpret Euler angles correctly, it is necessary to inspect the + conventions behind depends_on to resolve which of the many Euler-angle + conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + + + + + + + + + + + The set of misorientations expressed in quaternion parameterization + obeying symmetry operations for equivalent misorientations + as defined by crystal_symmetry and sample_symmetry. + + + + + + + + + Misorientation angular argument (eventually signed) following the same + symmetry assumptions as expressed for the field misorientation_quaternion. + + + + + + + + Misorientation axis (normalized) and signed following the same + symmetry assumptions as expressed for the field misorientation_angle. + + + + + + + + + + The set of disorientation expressed in quaternion parameterization + obeying symmetry operations for equivalent misorientations + as defined by crystal_symmetry and sample_symmetry. + + + + + + + + + Disorientation angular argument (should not be signed, see + `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) + following the same symmetry assumptions as expressed for the field + disorientation_quaternion. + + + + + + + + Disorientation axis (normalized) following the same symmetry assumptions + as expressed for the field disorientation_angle. + + + + + + + + diff --git a/base_classes/NXsample_component_set.nxdl.xml b/base_classes/NXsample_component_set.nxdl.xml new file mode 100644 index 0000000000..aa3a0e794f --- /dev/null +++ b/base_classes/NXsample_component_set.nxdl.xml @@ -0,0 +1,78 @@ + + + + + + + + number of components + + + + + Set of sample components and their configuration. + + The idea here is to have a united place for all materials descriptors that are not + part of the individual sample components, but rather their configuration. + + + + Array of strings referring to the names of the NXsample_components. + The order of these components serves as an index (starting at 1). + + + + + Concentration of each component + + + + + + + + Volume fraction of each component + + + + + + + + Scattering length density of each component + + + + + + + + Each component set can contain multiple components. + + + + + For description of a sub-component set. Can contain multiple components itself. + + + diff --git a/base_classes/NXsingle_crystal.nxdl.xml b/base_classes/NXsingle_crystal.nxdl.xml new file mode 100644 index 0000000000..44f6e92c30 --- /dev/null +++ b/base_classes/NXsingle_crystal.nxdl.xml @@ -0,0 +1,72 @@ + + + + + + Description of a single crystal material or a single crystalline phase in a material. + + There is the option of using Busing-Levy convention (as orginally designed in NXsample) + or using a more detailed description with NXrotation_set. + + + + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which can be derived from the lattice constants. + + + + + + + + + Detailed description of single crystal orientation and misorientation. + + + + + Unit cell of the single crystal. + + + diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml new file mode 100644 index 0000000000..84f83789a8 --- /dev/null +++ b/base_classes/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + Base class for a stage (lab) used to hold, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Stages provide a controlled + environment around the specimen. Stages enable experimentalists to apply + controlled external stimuli on the specimen. A stage_lab is a multi-purpose + /-functional tool that is constructed from multiple actuators, sensors, + and other components. + + With such stages comes the need for storing various (meta)data + that are generated while working and modifying the sample. + + Modern stages realize a hierarchy of components. Two examples are given to help + clarify how :ref:`NXstage_lab` instances should be used: Take a specimen that is + mounted on a multi-axial tilt rotation holder. This holder is fixed in the + support unit which connects the holder to the rest of the instrument. + Evidently different components are all considerable as to represent instances + of stages. + + In another example, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit to enable + careful specimen handling. Alternatively, a microtip is a silicon post + upon which e.g. an atom probe specimen is mounted. + Multiple microtips are grouped into a microtip array to conveniently enable + loading of multiple specimens into the instrument with fewer operations. + That microtip array is fixed on a holder. Fixture units in atom probe are known + as stubs. Stubs in turn are positioned onto pucks. Pucks are then loaded onto + carousels. A carousel is a carrier unit with which eventually entire sets of + specimens can be moved in between parts of the microscope. All of these units + can be considered stage_lab instances. + + The :ref:`NXstage_lab` base class reflects this hierarchy. To cover for an as flexible + design of complex stages as possible, users should nest multiple instances of + :ref:`NXstage_lab` according to their needs to reflect the differences between what + they consider as the holder and what they consider is the stage. + The alias field can be used to specify the community jargon if necessary. + + However, a much clearer approach to reflect the hierarchy of all :ref:`NXstage_lab` + instances is postfix each instance named stage_lab with integers starting + from 1 as the top level unit. + In the microtip example one could thus use stage_lab1 for the microtip, + stage_lab2 for the microtip array, stage_lab3 holder, etc. + The depends_on keyword should be used to additional clarify the hierarchy + especially when users decide to not follow the above-mentioned postfixing + notation or when is not obvious from the postfixes which stage_lab is at + which level of the stage_lab hierarchy. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to a stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of an at least three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. A typical + example are in-situ experiments using e.g. the tools of `Protochips <https://www.protochips.com>`_. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + We are looking forward to suggestions from the scientists. + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Free-text field to give a term how that a stage_lab at this level of the + stage_lab hierarchy is commonly referred to. Examples could be stub, + puck, carousel, microtip, clip, holder, etc. + + + + + The interpretation of this tilt should be specialized + and thus detailed via the application definition. + + + + + The interpretation of this tilt should be specialized + and thus detailed via the application definition. + + + + + The interpretation of this rotation should be specialized + and thus detailed via the application definition. + + + + + The interpretation of this position should be specialized + and thus detailed via the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + + diff --git a/base_classes/NXsubstance.nxdl.xml b/base_classes/NXsubstance.nxdl.xml new file mode 100644 index 0000000000..6d246ca224 --- /dev/null +++ b/base_classes/NXsubstance.nxdl.xml @@ -0,0 +1,119 @@ + + + + + + A form of matter with a constant, definite chemical composition. + + Examples can be single chemical elements, chemical compunds, or alloys. + For further information, see https://en.wikipedia.org/wiki/Chemical_substance. + + + + User-defined chemical name of the substance + + + + + Molecular mass of the substance + + + + + Unique numeric CAS REGISTRY number of the sample chemical content + For further information, see https://www.cas.org/. + + + + + CAS REGISTRY name of the sample chemical content + + + + + CAS REGISTRY URI + + + + + CAS REGISTRY image + + + + + Synonyms in the CAS system. + + + + + String InChi identifier. + The InChI identifier expresses chemical structures in terms of atomic connectivity, + tautomeric state, isotopes, stereochemistry and electronic charge in order to + produce a string of machine-readable characters unique to the respective molecule. + For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. + + + + + Condensed, 27 character InChI key. + Hashed version of the full InChI (using the SHA-256 algorithm). + + + + + Name according to the IUPAC system (standard). + For further information, see https://iupac.org/. + + + + + Identifier in the SMILES (Simplified Molecular Input Line Entry System) system + For further information, see https://www.daylight.com/smiles/. + + + + + Canonical version of the smiles identifier + + + + + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard:107 + This is the *Hill* system used by Chemical Abstracts. + + * Only recognized element symbols may be used. + * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. + * A space or parenthesis must separate each cluster of (element symbol + count). + * Where a group of elements is enclosed in parentheses, the multiplier for the + group must follow the closing parentheses. That is, all element and group + multipliers are assumed to be printed as subscripted numbers. + * Unless the elements are ordered in a manner that corresponds to their chemical + structure, the order of the elements within any group or moiety depends on + whether or not carbon is present. + * If carbon is present, the order should be: + - C, then H, then the other elements in alphabetical order of their symbol. + - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. + + + diff --git a/base_classes/NXunit_cell.nxdl.xml b/base_classes/NXunit_cell.nxdl.xml new file mode 100644 index 0000000000..b20c22cbc1 --- /dev/null +++ b/base_classes/NXunit_cell.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + Number of atom positions. + + + + + Description of a unit cell, i.e., the crystal structure of a single + thermodynamic phase. + + + + Identifier of an entry resolvable via crystallographic_database + which was used for creating this structure model. + + + + + Name of the crystallographic database to resolve + crystallographic_database_identifier e.g. COD, ICSD, or others. + + + + + A lattice system is a group of lattices with the same set of lattice point groups. + For further information, see https://en.wikipedia.org/wiki/Crystal_system. + + + + + + + + + + + + + + Crystallographic space group. + A space group is the symmetry group of a repeating pattern in space. + For further information, see International Table for Crystallography (https://it.iucr.org/). + + + + + Crystallographic point group. + A crystallographic point group is a set of symmetry operations, corresponding to one of the point groups in three dimensions, + such that each operation (perhaps followed by a translation) would leave the structure of a crystal unchanged. + This field should use Schoenflies notation (see Schoenflies, A., Krystallsysteme und Krystallstructur, 1891). + For further information, see https://dictionary.iucr.org/Point_group. + + + + + Laue group (also called Laue class). + The Laue classes are eleven geometric crystal classes containing centrosymmetric crystallographic types of point groups and their subgroups. + When absorption is negligible and Friedel's law applies, it is impossible to distinguish by diffraction between a centrosymmetric point group + and one of its non-centrosymmetric subgroups; only point groups belonging to different Laue classes can then be distinguished. + For further information, see https://dictionary.iucr.org/Laue_class. + + + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell vector a + + + + + + + For definining which coordinate system the unit cell vector a is defined in. + + + + + + Crystallography unit cell vector b + + + + + + + For definining which coordinate system the unit cell vector b is defined in. + + + + + + Crystallography unit cell vector c + + + + + + + For definining which coordinate system the unit cell vector c is defined in. + + + + + + Crystallography unit cell angles alpha, beta, and gamma + + + + + + + + Volume of the unit cell + + + + + + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + + + + + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + + + + + Identifier for the phase. + The value 0 is reserved for the unknown phase which represents the null-model + that no phase model was sufficiently significantly confirmed. + + + + + Trivial name of the phase/alias. + + + + + Labels for each atom position + + + + + + + + The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + Atom positions x, y, z. + + + + + + + + Reference to an instance of NXcoordinate_system whereby the positions can be + resolved. + + + + + + Relative occupancy of the atom position. + + + + + + + + For definining which coordinate system the unit cell parameters are defined in. + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml deleted file mode 100644 index 8dd7a6da55..0000000000 --- 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/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index c2276f3a93..0000000000 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml deleted file mode 100644 index b6cd467a2b..0000000000 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_set.nxdl.xml deleted file mode 100644 index a482480c85..0000000000 --- a/contributed_definitions/NXimage_set.nxdl.xml +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Container for reporting a set of images taken. - - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center of mass along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center of mass along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3c..0000000000 --- a/contributed_definitions/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml deleted file mode 100644 index 92be5ae595..0000000000 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml deleted file mode 100644 index dff2584fcf..0000000000 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - Extension of NXpositioner to include fields to describe the use of manipulators - in photoemission experiments. - - - - Name of the manipulator. - - - - - A description of the manipulator. - - - - - Type of manipulator, Hexapod, Rod, etc. - - - - - Is cryocoolant flowing through the manipulator? - - - - - Temperature of the cryostat (coldest point) - - - - - Power in the heater for temperature control. - - - - - Temperature at the closest point to the sample. This field may also be found in - NXsample if present. - - - - - Current to neutralize the photoemission current. This field may also be found in - NXsample if present. - - - - - Possible bias of the sample with trespect to analyser ground. This field may - also be found in NXsample if present. - - - - - Class to describe the motors that are used in the manipulator - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the manipulator as a component in the instrument. Conventions from - the NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml deleted file mode 100644 index 4a030c6844..0000000000 --- a/contributed_definitions/NXpeak.nxdl.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d2728..0000000000 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - -